Re: shipping an aggregate device
Re: shipping an aggregate device
- Subject: Re: shipping an aggregate device
- From: Jeff Moore <email@hidden>
- Date: Wed, 27 May 2009 14:09:45 -0700
The deprecation of AudioDeviceRead() doesn't really affect your plug-
in. It should continue to support AudioDeviceRead(). In fact, I don't
imagine that your plug-in should have to change one bit because of this.
That comment is there for apps that are currently using AudioDeviceRead
() so that they have some idea of what to do to move to more current
API. The reason for this advice is that the common usage case for
AudioDeviceRead() was to allow an app to piggy back reading input data
from one device onto the IO cycle of another device. Using an
aggregate device instead of this convoluted construct provides a
cleaner and more flexible interface to the same functionality.
On May 27, 2009, at 1:49 PM, Alex Sheh wrote:
Currently we implement an AudioHardwarePlugInInterface, which
aliases any audio driver on the system, by basically forwarding any
audio requests onto the aliased audio driver. However, since
AudioDeviceRead() has been deprecated and the documentation
recommends using an aggregate device instead, we are planning on
rewriting our plugin as an aggregate device.
Does this sound like the correct approach? Or are there any
limitations that I would run into in terms of replicating this
"aliased audio driver/forwarding audio requests" behavior with an
aggregate device? Is it possible to build the aggregate device into
a bundle, so that we can ship it to the customer as a plugin?
I found a posting called "Creating Core Audio aggregate devices
programmatically" at http://www.thismuchiknow.co.uk/?p=51. Does
anyone know of other documentation that would be helpful?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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