Re: Can't set kAudioSubDevicePropertyDriftCompensation
Re: Can't set kAudioSubDevicePropertyDriftCompensation
- Subject: Re: Can't set kAudioSubDevicePropertyDriftCompensation
- From: Ed Wynne <email@hidden>
- Date: Thu, 03 Apr 2014 10:04:11 -0400
It's not the running of the run loop that is the bulk of problem.
CoreAudio is implemented as a client/server architecture (for the most part). The server exists in coreaudiod and the clients are in any app using the CoreAudio.framework. All of that is just fine, except the way its implemented suffers from a classic synchronization / race condition problem.
For some very stateful API changes, like device creation, a client calls through to the server and everything happens in the server. The server then asynchronously notifies all clients of the new state. This state update is quick, but not instantaneous, and is not synchronized in any way to the client or the call that caused it.
So what you get is the original client call, that requested the device creation, will usually return success before the client it is running in has actually been notified by the server of the new state (i.e., the devices existence). So any further calls made by the client referencing the new device, in the window between successful return and the server notification, will fail because the device doesn't exist for it yet.
There are many other examples of this problem in the CoreAudio APIs, but this one seems to be the most common one that people hit.
The commonly repeated work around for this problem is to simply wait a bit. This allows the server notification to come in and synchronize the client's state. That is simply terrible advice, but it does usually work. Waiting will never deterministically close the window, but it can make it vanishingly small (provided you wait long enough). For people who've used Djay, that 2-3s progress bar delay that says "Reconfiguring audio devices" anytime you mess with the recording device preferences. Now you know what that is doing. Nothing, literally. It's just waiting.
The better more correct solution is to wrap the device creation API call with a polling loop that just waits for the new device to show up. It's about 10 lines of code and is entirely deterministic, and closes the window entirely. It is also usually much faster. The notification usually comes in very quickly, a few tens of microseconds. Unfortunately, the scheduler gets to decide, and on a busy machine that is paging, it can sometimes take hundreds if not thousands of times longer.
-Ed
On Apr 3, 2014, at 2:32 AM, AI Developer <email@hidden> wrote:
> Or you can tell CoreAudio to run it's own run loop...
>
> See the following discussion:
>
> http://lists.apple.com/archives/coreaudio-api/2009/Oct/msg00214.html
>
> You can write something like this in your app startup code.
>
> CFRunLoopRef nullRunLoop(0);
> OSStatus err = AudioHardwareSetProperty (kAudioHardwarePropertyRunLoop, sizeof(CFRunLoopRef), &nullRunLoop);
>
>
> Thanks.
> Devendra.
>
> On 3/31/14 11:25 PM, Jeff Johnson wrote:
>> For the record, it turns out that there was no problem with the code, but I had to run the run loop for a fraction of a second before calling it, because ... ugh?
>>
>>
>> On Mar 31, 2014, at 11:34 AM, Jeff Johnson <email@hidden> wrote:
>>
>>> I can successfully create an aggregate device with kAudioPlugInCreateAggregateDevice. I can successfully add subdevices to the aggregate device with kAudioAggregateDevicePropertyFullSubDeviceList. I can successfully set one of the subdevices as the master clock with kAudioAggregateDevicePropertyMasterSubDevice. I can successfully get the objectIDs of the subdevices with kAudioObjectPropertyOwnedObjects. However, I am unable to set kAudioSubDevicePropertyDriftCompensation for any of the subdevices using AudioObjectSetPropertyData(). I've tried at least a dozen different combinations of parameters for the function, but I always get kAudioHardwareUnknownPropertyError. Does anyone know the magic combination to get this to work? FWIW, I'm running Mac OS X 10.8.5.
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
_______________________________________________
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