Re: Race condition when changing data source?
Re: Race condition when changing data source?
- Subject: Re: Race condition when changing data source?
- From: Jeff Moore <email@hidden>
- Date: Thu, 31 Oct 2013 18:15:52 -0700
It sounds like you are making a bad assumption with your interaction with the HAL. Specifically, it seems like you are expecting that when you call AudioObjectSetPropertyData to change the selector control’s value, the control value is changed immediately upon the call returning no errors.
This is incorrect.
The HAL is an asynchronous API. If AudioObjectSetPropertyData returns no error, all you know at that point is that the request to make the change has been accepted. You can’t expect that the value has actually changed until you receive the notification saying so.
Note that the same is true for the volume and mute controls. You need to pay attention to the various properties relating to them sending notifications about when they change. You can’t just assume that they change.
—
Jeff Moore
Core Audio
Apple
On Oct 30, 2013, at 8:09 AM, Tim Hewett <email@hidden> wrote:
> I have a USB S/|PDIF adaptor with two user-selectable data sources - Speaker and External S/PDIF Interface. Using the Core Audio API I am setting the data source to get the status of all the volume and mute controls, i.e. their existence and writability, which involves discovering the maximum number of channels supported on the stream and setting the device to the maximum number of channels temporarily (so that the volume and mute controls can all be interrogated).
>
> I find that most of the time the API reports than no volume or mute controls exist, even though they are shown in Audio MIDI Setup. If I run under a debugger and set a breakpoint just after setting the data source, then continue execution, the correct values are returned. It seems there is a race condition.
>
> Now I have it do:
>
> while ( CFRunLoopRunInMode( kCFRunLoopDefaultMode, 1, TRUE ) == kCFRunLoopRunHandledSource );
>
> just after setting the data source, and get consistent results, but it would be better to synchronise with Core Audio and only continue once all the consequences of changing the data source have propagated.
>
> Is there some way to block on Core Audio for this, or if not, poll it? I guess that listeners on these properties will only be called once the changes happen, maybe an option, but it would be preferable to be able to get the properties directly in this context.
_______________________________________________
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