Re: Aggregate question device
Re: Aggregate question device
- Subject: Re: Aggregate question device
- From: Jeff Moore <email@hidden>
- Date: Mon, 16 Nov 2009 11:45:16 -0800
On Nov 16, 2009, at 11:03 AM, Stéphane Letz wrote:
> Hi,
>
> We use code to create aggregate devices dynamically in our application (one input device and one output device). We force both devices to use the same sampling rate and input device is chosen as the "master". So far so good if both devices share the same clock (which is the case with input/output on Mac pro, MacBook Pro Intel machine right?).
To my knowledge, that is correct.
> But if aggregating devices in a more general sense, how can we know what should be done? Should "kAudioSubDevicePropertyDriftCompensation" property be used to know if devices do not share the same clock? Possibly warn the user (if resampling is not wanted..) or using "kAudioSubDevicePropertyDriftCompensationQuality" to activate resampling?
>
> What is the recommended strategy? Any code sample?
The device property, kAudioDevicePropertyClockDomain, helps figure out which devices are synchronized in hardware and which aren't. The way it works is that if two devices have the same value for this property and that value is not 0, then the two devices are synchronized in hardware.
When it is the case that you want to aggregate two devices that are not synchronized in hardware, you can tell the aggregate device to apply drift compensation. This can be done when you create the aggregate device by adding the key, kAudioSubDeviceDriftCompensationKey, with a non-zero value to the dictionary that describes the sub-device that requires the compensation. Note that no matter whether the drift compensation is enabled or not, the master sub-device will never have compensation applied to it. Also note that while kAudioSubDeviceDriftCompensationQualityKey is defined in the header, it doesn't do anything at the moment.
I don't have any sample code, but here's something I pulled from a test tool I use. It makes heavy use of several C++ wrappers for both HAL objects and CF objects that can be found in PublicUtility. In this example, I'm building the sub-device list portion of an aggregate device description. I iterate through the device list and add entries for all the built-in devices. I am turning the drift compensation off explicitly here (it's also off by default). To turn it on, you would just change the value of kAudioSubDeviceDriftCompensationKey from 0 to 1.
CACFArray theSubDeviceDictionaryList(true);
UInt32 theNumberDevices = theAudioSystemObject.GetNumberAudioDevices();
CAAutoFree<AudioObjectID> theDeviceList(theNumberDevices);
theAudioSystemObject.GetAudioDevices(theNumberDevices, theDeviceList);
for(UInt32 theDeviceIndex = 0; theDeviceIndex < theNumberDevices; ++theDeviceIndex)
{
CAHALAudioDevice theDevice(theDeviceList[theDeviceIndex]);
if(theDevice.GetTransportType() == kAudioDeviceTransportTypeBuiltIn)
{
CACFDictionary theSubDevice(true);
CACFString theDeviceUID(theDevice.CopyDeviceUID(), true);
theSubDevice.AddString(CFSTR(kAudioSubDeviceUIDKey), theDeviceUID.GetCFString());
theSubDevice.AddUInt32(CFSTR(kAudioSubDeviceDriftCompensationKey), 0);
theSubDeviceDictionaryList.AppendDictionary(theSubDevice.GetCFDictionary());
}
}
Hope this helps. Let me know if you have any questions.
--
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