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: "B.J. Buchalter" <email@hidden>
- Date: Wed, 18 Jun 2003 02:16:29 -0400
>
I do not believe that this is exactly true. There is at least one CoreAudio
>
device which supports configuration choices which improve efficiency when all
>
channels are not needed. With the kAudioStreamPropertyStreamFormatMatch and
>
kAudioStreamPropertyPhysicalFormatMatch properties, it is fairly easy for an
>
application to find the most efficient format for the device.
Yes, but this is a global change, and certainly not something that would be
supported by a simple app. The point is, if you have a device that supports,
say, 32 in/32 out and is being used by one app with 2 out, and another app
with 6 out and 16 in. Changing the physical format does not solve the
problem. Each app needs to tell the HAL how many channels it wants to use.
There is an API defined for this.
As you point out, the savings is not in the App itself -- it can just ignore
the channels it does not want to use. The potential savings is in not having
to mix and convert channels (or streams) that are not being used by a
client. The potential savings is huge in wide devices.
>
I'm not sure what other audio devices support in their CoreAudio driver, but
>
even if there are a lot of permutations, it seems that the *FormatMatch
>
properties would save the application developer from wading through any more
>
possibilities than are appropriate. Perhaps this is not the most
>
straightforward way to configure channel usage, but I believe that it is
>
workable if CoreAudio driver developers support it (providing that the
>
hardware actually supports this).
The Physical Format stuff makes sense if the specific format requires the
hardware to change its capabilities. AFAIK, USB bandwidth is sufficently
limited that you cannot actually run 6 channels 96/24 (at least
bidirectionally). So if you choose such a 96k/24bit format the device
capabilities change. This is a feature driven set of formats and is limited
so it makes sense. It does not make sense to do channel/stream enables with
this method because it is too nebulous, and one clients decisions are not
correct for another client. The classic example of this is iTunes and any
DAW. Itunes (in the current incarnation) needs 2 channel out, period. The
DAW may need a variety of I/O configs, depending on the moment. It does not
make sense for the device to present itself as 2 channels out just for
iTunes efficiency when the DAW may need all 64 in and 12 out (or even 64
out). But it does make sense for the client to communicate these
(instantaneous) requirements to the HAL and the driver.
>
In addition, I believe that the output callback prepares the buffers with
>
silence, so an application merely needs to skip unused channels without
>
specifically filling them with new data. This does not save the CoreAudio
>
engine from mixing all channels for all clients, but it represents some amount
>
of savings.
Again, there are stream enables. If you disable a stream, the HAL will not
present your IOProc with a buffer for that stream. The problem is as you
point out in the following:
>
Since the device can only be in one mode at a time, and the real efficiency
>
concerns are the final transfer from CoreAudio to the device, I don't believe
>
that there would be any advantage to allowing individual applications to
>
provide fewer channels than are currently configured on the device. If this
>
level of efficiency is needed, I believe that applications can simply ignore
>
unused channels, except in computing how to skip over them in the data
>
buffers.
>
There are certainly ways to code this which make N channels as efficient as
>
possible, whether CoreAudio is asking for N channels in the callback or N+M
>
channels.
The problem is that the mix and convert routines (especially the input
routines) are expensive, and it does not make sense to run them for a client
that does not need them. The API supports this (especially for drivers that
export Mono streams -- they can be turned on or off per channel with the HAL
API as it stands today). 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.
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.