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: Mon, 14 Jul 2003 20:22:13 -0700
I don't think so. The mix buffer is something separate. You would need
to scan the clientBufferSetList in each IOAudioEngineUserClient to see
how many buffers are registered. Another way to do it would be to
override registerClientBuffer() and unregisterClientBuffer() in
IOAudioEngineUserClient and tag your work onto the end.
On Monday, July 14, 2003, at 6:32 PM, Matt Gonzalez wrote:
Hi Jeff-
I'd like to add support for this to our driver. Is it sufficent to
call getMixBuffer for each stream to determine if a buffer has been
registered or not?
That is:
if (stream->getMixBuffer() != NULL)
enable DMA for this stream
Thanks,
Matt
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.
_______________________________________________
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.