Re: AudioServerPlugIn / kAudioDevicePropertyStreams
Re: AudioServerPlugIn / kAudioDevicePropertyStreams
- Subject: Re: AudioServerPlugIn / kAudioDevicePropertyStreams
- From: Brian Willoughby <email@hidden>
- Date: Thu, 27 Nov 2014 12:06:21 -0800
Hi Steve,
I have a distant recollection of one of Apple's CoreAudio engineers stating that it makes a difference whether applications use some or all streams on a device, because the driver will only do the processing to mix the streams that are in use. In other words, if your application code is enabling all streams, but only writing audio to a couple of streams, leaving the rest silent, then this is less efficient than simply turning off those unused streams. That's because the driver will be mixing silence in the former case, but skipping that step in the latter case.
In addition, I can't remember whether the concept also applies to channels within a stream.
Unfortunately, it's been a while since I looked at those details, so I forget which CoreAudio mechanism allows an applications to turn streams on or off.
But you might be able to find something by searching the CoreAudio Mailing List archive for messages from apple.com that have the appropriate key words.
Brian Willoughby
Sound Consulting
On Nov 25, 2014, at 10:12 AM, Steven Toth <email@hidden> wrote:
>
> (First time poster)
>
> Hello all.
>
> I think I've misunderstood something related to Audio Server Plugins,
> hopefully someone with more experience can comment. (OSX 10.9 or
> 10.10).
>
> I'm writing a userspace driver that exposes multiple independently
> operated stereo audio streams (LPCM 44.1). The requirement is that
> each audio stream is selectable as a valid audio input via a typical
> AVFoundation application, run independently and deliver its own PCM
> samples without any impact on other 'streams' within the device.
>
> In other words, a device that can have none-or-more of its streams
> running, while other streams within the same device are idle. I
> thought CoreAudio allowed that, by exposing N x streams. I think I'm
> wrong.
>
> Evidence tells me that the APIs (Eg. StartIO) have no concept of a
> single stream running on its own. The entire Device is started and
> expected to deliver samples on each stream, in fact I see this during
> testing. Calls to DoIOOperation for all exposed streams within the
> same Device are received.
>
> If my initial design assumptions are incorrect, what's the preferred
> way to achieve my goal?
>
> Perhaps create multiple .driver binaries, each with their own UUID and
> have coreaudiod load each like its own independent driver?
>
> Attempts to register multiple plugin uuids in the .driver plist array,
> to instruct coreaudiod to register multiple devices from a single
> .driver, result in only the first device being created. Pity.
>
> I'd welcome feedback on this. Thanks,
>
> - Steve
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden