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: Kurt Bigler <email@hidden>
- Date: Wed, 18 Jun 2003 11:15:39 -0700
on 6/17/03 11:16 PM, B.J. Buchalter <email@hidden> wrote:
>
> 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.
Yes, and you're not even mentioning the increased bandwidth over a shared
bus, such as Firewire. This is not just a multi-app mixing issue. If only
a single audio app is running and it is using a fraction of the available
channels, this makea difference in the amount of data that needs to be
transmitted/received over Firewire. And this would mean DMA is running for
all the unneeded channels, wasting bandwidth on another limited resource.
I'm surprised you don't mention this, so I wonder if I'm missing something.
Presumably the same channel enable information, if provided to the driver,
would allow the driver to do only the DMA that is actually needed. Doing
this based on zeroed buffers or silent-buffer flags would probably not be
practical on Firewire where presumably isoch transfer modes need to be set
up in advance of starting transport.
-Kurt Bigler
_______________________________________________
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.