Re: Bug in IOAudioStream?
Re: Bug in IOAudioStream?
- Subject: Re: Bug in IOAudioStream?
- From: BlazeAudio Developer <email@hidden>
- Date: Thu, 18 Aug 2005 17:07:56 +0530
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:
This email sent to email@hidden