Re: Bug in IOAudioStream?
Re: Bug in IOAudioStream?
- Subject: Re: Bug in IOAudioStream?
- From: Jeff Moore <email@hidden>
- Date: Mon, 29 Aug 2005 12:35:14 -0700
Subclass IOAudioStream and call it as part of some other method? This
is C++ we're talking about here so I figured that went without saying.
That said, the fact that this does not work correctly in the first
place probably points to a problem with the way you have written your
driver. So far, I have written a few drivers of varying complexity,
including one that has streams that come and go, that have never had
any problems like this.
One thing I did learn the hard way was that there is no easy way to
remove just one stream from an engine. The way IOAudioEngine works
requires you to get rid of all of your streams by calling
detachAudioStreams() before you can do an operation like that.
Because detachAudioStreams() calls terminate() on the streams as part
of "detaching" them, the old stream objects are dead when that call
returns. You have to instantiate a new set of stream objects and re-
add them to the engine to reflect the new state of your device. (BTW,
you should also wrap a change like that with beginConfigurationChange
()/completeConfigurationChange() to make sure the right notifications
get sent.)
On Aug 27, 2005, at 5:14 AM, BlazeAudio Developer wrote:
Any more pointers on how we should be setting our starting channel
number, since the setStartingChannelNumber() is a protected member?
Thanks.
Devendra.
At 05:07 PM 8/18/2005, BlazeAudio Developer wrote:
At 12:12 AM 8/16/2005, Jeff Moore wrote:
I was puzzled by this.
So, I started looking at the IOAudoiFamily code to see where this
property gets set/updated.
And in doing so I found out that in my case, this should get
updated from IOAudioStream::setformat() function. However, the
IOAudioEngine::updateChannelNumbers() is called only if the "old"
format and the new format have a different number of channels.
However, if it is a "new" stream, and if setFormat is being called
the first time, the "old" format is essentially not set,
uninitialized..
This is one place where it is updated. My quick search through the
sources found several others. That said, there's nothing stopping
your driver from manually calling
IOAudioStream::setStartingChannelNumber()
Jeff, I don't know if you have the same headers that I do. But in
my version of IOAudioStream headers, setStartingChannelNumber() is
a protected member. The only friends that IOAudioStream has are
IOAudioEngine and IOAudioEngineUserClient.
How can we call it from our class (which is derived from
IOAudioEngine)?
So, I guess there is that something that's stopping me from
calling setStartingChannelNumber().
I tried to find where the IOAudioStream's member "format" is
initialized, but I could not find any initialization for this
member.
There's no magic in the Family for guessing the initial format. You
have to explictly set the initial the format of the stream.
I agree with you. And the initial format is set with setFormat()
call, Right?
If so, then setFormat() should not depend on the "old" value of
the unitialized format value, because, as you said, there's no
magic in the Family for guessing the initial(old) format.
In any case, IMHO, and I think you would agree, that it's improper
for any code to compare values against a potentially uninitialized
member/variable.
Generally, this is done prior to activating the stream by calling
setFormat on the stream.
Exactly, and that's what I'm doing.
So, comparing the channel count of the new format, against an
uninitialized member does not make sense.
I guess I was getting lucky with the first two streams (perhaps the
member was being initialized to a value of 0), and with the third
stream the format's number of channels was probably 2 to begin
with, and so caused it not to be invoked.
I ended up calling updateChannelNumbers() on the engine from my
code that creates the streams, and it started working fine.
I don't see this as a bug in the Family. I see this as a bug in your
driver for not following SOP for setting up your stream.
And according to you the SOP is calling a protected member?
It seems to
me that this would have been avoided if you had initialized your
streams fully, including their formats, prior to adding them to the
engine with the call to addAudioStream().
As far as I can tell, I am doing exactly this.
But I do not see how the starting channel number property can be
properly set following these procedures.
Your help in this matter is greatly appreciated.
Thanks.
Devendra.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40blazeaudio.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden