Re: Stream enables [was: fIsMixable]
Re: Stream enables [was: fIsMixable]
- Subject: Re: Stream enables [was: fIsMixable]
- From: "B.J. Buchalter" <email@hidden>
- Date: Tue, 17 Jun 2003 22:09:04 -0400
Hi Devendra,
>
Actually, it is possible to do that with CoreAudio today (we have it
>
running in one of our drivers).
You can enable the use of stream enables, but it is meaningless. See below:
>
This requires creating multiple streams on a single AudioEngine (pretty
>
much like the ASIO channels).
Yes, but even if you do, the driver cannot optimize on the basis of stream
enables, and the amount of optimization that the HAL can do is trivial. So,
while the API is present, the feature is not implemented in any meaningful
way.
>
However, if the hardware requires you to send data for all the (20 or
>
so!) channels to be present in the DMA buffer, the driver has the task of
>
putting the data in appropriate "slots" - but that also applies for ASIO!
No -- it doesn't. In ASIO the driver is informed which channels are active,
so it can optimize for unused slots. In the current CoreAudio implementation
only the HAL has access to the stream enable data, and the driver is unable
to take advantage of possible optimizations. Since all drivers are
responsible for converting Fixed<->Float, there are significant possible
optimizations that the driver could make if it were aware of the stream
enables.
To the HAL folks: I have a bug in on this and I have a DTS incident on this
(neither of which have gone anywhere) -- it is a real problem for those of
us who make devices that can support literally > 100 channels (streams).
Users do not understand why a driver would take more CPU when they are "only
doing stereo". The current situation is a step back from ASIO. Please
propagate the stream enable information down to the userclient so that we
can optimize our drivers for dynamic channel allocation.
On a similar note -- the current implementation of the HAL/USERCLIENT causes
the driver to do INT->FLOAT conversions for all input channels of all
clients! This means that if N clients are running, all the drivers do N
conversions for each input sample. This is incredibly wasteful, especially
if the client isn't even using the input (like iTunes). Please let's think
about how to get this fixed. I think it would be possible for a driver to
fix this by replacing parts of the user client, but the problem is that this
is something that affects all drivers, and as such really ought to be fixed
in the IOAudioFamily.
>
Please note that we ran across some applications' older versions which
>
did not work well with this scheme (multiple output streams on a single
>
AudioEngine) - but most newer applications work properly with this
>
approach.
Right; those apps were broken. Luckily, most developers have realized this
(due in no small part to Apple staunchly supporting that initial design
requirement and not allowing the problem to degenerate into a large series
of compatibility hacks -- thanks Jeff & Bill!), and have fixed their code.
Best regards,
B.J. Buchalter
Metric Halo
M/S 601 - Building 8
Castle Point Campus
Castle Point, NY 12511-0601 USA
tel +1 845 831-8600
fax +1 603 250-2451
If you haven't heard ChannelStrip yet, you don't know what you're missing!
Check out SpectraFoo, ChannelStrip and Mobile I/O at
http://www.mhlabs.com/
Download a 12 day demo from <
http://www.mhlabs.com/demo/>
_______________________________________________
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.