Re: efficient device channel enabling - was Re: fIsMixable
Re: efficient device channel enabling - was Re: fIsMixable
- Subject: Re: efficient device channel enabling - was Re: fIsMixable
- From: Jeff Moore <email@hidden>
- Date: Wed, 18 Jun 2003 14:40:02 -0700
The IOAudio family keeps a list of all this stuff on your behalf in the
user client object for either the Engine or the Stream (I don't recall
which offhand). You can also override the user client routine the HAL
calls to register/unresgister IO buffers and track it that way too.
My point here is that none of this info is hidden from you, but you
might have to go digging through parts of the Family you haven't been
looking at yet.
On Wednesday, June 18, 2003, at 1:41 PM, BlazeAudio Developer wrote:
Jeff,
It seems to me that I'm missing something here.
Say I have a 32 channel device - and I have one stream corresponding to
each channel - so there are 32 mono streams (output).
When the performAudioEngineStart() call on the AudioEngine comes in,
how
is the driver to know which of the 32 streams are active?
Thanks.
Devendra.
At 12:02 PM 6/18/2003, Jeff Moore wrote:
The driver knows exactly what streams are in use at all times. They
are the ones that the HAL has registered buffers with for doing IO.
If there isn't a buffer registered, then the stream is inactive. How
much more info do you need?
Further, the HAL registers it's buffers prior to doing any IO in a
routine that is not time critical. So the driver has ample
opportunity to do the right thing for their hardware, whatever that
might be, when streams become enabled/disabled. The tricky thing here
is that different processes are going to have different sets of what
streams are enabled/disabled, but again, the driver knows about all
this long before the HAL makes the first call to performClientIO.
This is a very different situation from ASIO, to say the least.
To date, there haven't been too many apps that have taken advantage
of the ability to enable and disable streams. I'm not entirely sure
why that is, but at least part of that is our fault. We have not
fully implemented that support in the HAL Audio Units or in the Sound
Manager. This will be fixed as time progresses.
That doesn't change the fact that direct HAL clients have to be
responsible for their own behavior. They really need to turn off
streams they aren't using. The HAL can't do it automagically for them
for backward compatibility reasons. The stream enable/disable stuff
was first implemented in 10.2. Prior to that, HAL clients could
assume that all the streams were always enabled. Changing that
assumption breaks existing apps, so we can't change it.
For the record, I have used the stream enable/disable stuff myself to
properly scale the CPU bandwidth used by a driver that has many
streams (over 100). I know it works as it is intended to work,
provided the driver is smart enough and has hardware that can take
full advantage of it and scale it's work accordingly.
On Tuesday, June 17, 2003, at 11:16 PM, B.J. Buchalter wrote:
The problem is that the drivers are not given
knowledge of the stream enable states by the HAL, so they have no
way of
applying appropriate optimizations based upon stream usage.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.