Re: Stream enables [was: fIsMixable]
Re: Stream enables [was: fIsMixable]
- Subject: Re: Stream enables [was: fIsMixable]
- From: "B.J. Buchalter" <email@hidden>
- Date: Wed, 18 Jun 2003 09:32:40 -0400
on 6/18/03 2:13 AM, Brian Willoughby at email@hidden wrote:
>
>
I certainly understand that a stereo application cannot guarantee that its two
>
output will appear on the proper channels of a surround output device, but
>
let's assume that this can be handled. What I would like is for the stereo
>
application to mix into the surround stream if another application is playing
>
surround output, but I would prefer to switch the audio device to a
>
stereo-only physical format if no other application needs more than two
>
channels.
This is a very good question. Jeff?
I do know that there is a HAL property that drivers (and clients) can
support that specifies the preferred stereo channels for a multi-channel
device. This may be helpful for your application. It seems to me that simple
Apps probably should not change the physical format unless they absolutely
need to (e.g. A surround app would change the format to meet its minimum
needs or to support AC3 transport or such), and should use the channel hints
to determine where to send its simple channels. It should also probably have
an "advanced" preference to all the user to route its outputs within the
selected device -- I know that our users would really appreciate this with
iTunes (and other music players) because they could then route the iTunes to
a different set of channels from other simple apps and thuse use our mixer
for volume control, etc.
>
P.S. I am wondering why CoreAudio or the device driver cannot mix all client
>
input as float values before doing a single conversion from float to the
>
native device format.
It does. But currently altivec is not supported in the kernel, so even this
is nontrivial. The big thing is that for each client you have to
1) Convert all inputs from device->float
2) Mix all outputs
And then for each output
(3) Convert mixed stream from float->device.
If the driver knew which streams were disabled, it could skip (1) and (2) on
disabled streams for each client and skip (3) for streams that are disabled
on all clients, as well as skipping zero filling buffers that are clean
and/or unused.
>
Is there a reason why the conversions are done per client? Or
>
am I missing a distinction between input and output? Are you talking about
>
recording audio from the device inputs to multiple client applications, or
>
playing audio from multiple client applications to the device outputs?
See above. If iTunes plays to two channels, all output channels are mixed
and converted, and all input channels are converted on its behalf. Since the
input path is done per client, each client causes the expensive
device->float process once per sample per client, even if the client is not
using the stream!!!!
BTW, you can see these behaviors by running CHUD/Shikari when playing iTunes
with internal input and output -- you will see the DBDMA driver's input and
output convert routines in the histogram, and they will be a non-trivial
amount of CPU. Note that the input routine takes more time than the output
routine, even though iTunes does not use the input at all. Also note that
this is for stereo/16 bit. Think about 18/18 24 bit @ 96k and you begin to
see my concern...
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.