Re: Bug in IOAudioStream?
Re: Bug in IOAudioStream?
- Subject: Re: Bug in IOAudioStream?
- From: Jeff Moore <email@hidden>
- Date: Mon, 15 Aug 2005 11:42:10 -0700
On Aug 13, 2005, at 12:15 AM, BlazeAudio Developer wrote:
I am working on an audio driver in which the Streams are created at
a "later" time - that is after the Engine is created/initialized.
In this case, I am creating three streams. One Stereo Output
Stream, One 16 ch. Input stream, and one more Stereo Input Stream.
All three streams get created fine. However, CoreAudio applications
are able to see only the Stereo output and the 16 channel Input
stream. They cannot see the second stereo input stream.
Looking at the IORegistry I see that all three streams are present,
but the IOAudioStreamStartingChannelNumber property for the third
stream is missing.
This is why the HAL ignores this third stream. That property is vital
so that the HAL knows what order to present the streams in the IOProc.
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() as appropriate for your
device.
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.
Generally, this is done prior to activating the stream by calling
setFormat on the stream.
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. 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().
--
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