Re: Initialisation problem when creating an aggregate device programmatically
Re: Initialisation problem when creating an aggregate device programmatically
- Subject: Re: Initialisation problem when creating an aggregate device programmatically
- From: Dave Addey <email@hidden>
- Date: Wed, 20 Aug 2008 15:10:00 +0100
- Thread-topic: Initialisation problem when creating an aggregate device programmatically
Title: Re: Initialisation problem when creating an aggregate device programmatically
An update to my own email:
Looks like I spoke too soon. After extensive testing, I was still getting the same problem very occasionally, even with the call to retrieve the composition dictionary.
It looks as though retrieving the composition dictionary was taking a short but usually-just-long-enough amount of time, giving the aggregate device changes time to catch up. Possibly the call wasn’t actually doing any specific initialisation after all. It seems similar to the other known issue with aggregate device creation.
So, what I’m trying now is:
* Create a CFDictionary for my aggregate device, adding in a kAudioAggregateDeviceNameKey and kAudioAggregateDeviceUIDKey
* Get the CoreAudio plugin
* Feed the CFDictionary to the plugin, to create a blank aggregate device
* Call CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false) to give the aggregate device chance to catch up
* Set the kAudioAggregateDevicePropertyFullSubDeviceList property to a CFArray containing the UID for the device I want to use
* Call CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false) to give the aggregate device chance to catch up
* Set the kAudioAggregateDevicePropertyMasterSubDevice property to the device I want to use
* Call CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false) to give the aggregate device chance to catch up
The third call to CFRunLoopRunInMode might be overkill, but I’m not taking any risks.
This seems to be working reliably now (although I will be trying it several hundred times to be sure).
All of which begs the question: is there a way to definitively check whether the device is currently available and valid? Relying on a “wait for a bit” approach seems clunky at best. Any of the approaches I’ve tried – mainly, retrieving properties of the new aggregate device – claim to have worked fine, even when the device subsequently turns out not to be valid.
Dave.
From: Dave Addey <email@hidden>
Date: Wed, 20 Aug 2008 13:26:59 +0100
To: <email@hidden>
Subject: Initialisation problem when creating an aggregate device programmatically
Hi all,
I am creating an aggregate device programmatically. I ran into a problem, which I think I have found a workaround for. But it’s a weird workaround, so I thought I should check I’m doing things the right way.
In my tests, I’ve been creating an aggregate device for a single output device. Here’s the problem. Sometimes my aggregate device would be created perfectly, sometimes it would not. Checking it with Audio MIDI Setup showed that when it was not created properly, no devices were selected as “in use” for the device. (I checked this by opening Audio MIDI Setup, selecting “Properties For” for my device, and clicking on “Configure Device”. None of the available devices had a check in the “Use” column.) Other times, it would be created fine, and the correct device would be checked in the “Use” column.
(Note: I have read about another problem when initialising new aggregate devices, and so I am calling CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false), as described elsewhere, to avoid that know issue.)
To try and work out what was going wrong, I decided to retrieve the kAudioAggregateDevicePropertyComposition property, immediately after setting the kAudioAggregateDevicePropertyFullSubDeviceList property. Looking at the contents of the composition dictionary showed that the device seemed to be initialised correctly. And to my surprise, the device started working every time! It seems as though the call to get kAudioAggregateDevicePropertyComposition fixed the occasional problem I was seeing.
Could it be that retrieving kAudioAggregateDevicePropertyComposition causes some device initialisation to take place? Certainly it solves the problem I was having. Or is this symptomatic of something else I should have been doing all along?
Here’s a quick pseudo-code overview of what I am doing:
* Create a CFDictionary for my aggregate device, adding in a kAudioAggregateDeviceNameKey and kAudioAggregateDeviceUIDKey (note: I don’t make it a private device)
* Get the CoreAudio plugin
* Feed the CFDictionary to the plugin, to create a blank aggregate device
* Call CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false) to make sure that everything completed correctly
* Set the kAudioAggregateDevicePropertyFullSubDeviceList property to a CFArray containing the UID for the device I want to use
* Retrieve the kAudioAggregateDevicePropertyComposition dictionary (this seems to ensure that initialisation works every time, as described above)
* Set the kAudioAggregateDevicePropertyMasterSubDevice property to the device I want to use
Have I missed out a stage, or should I be filing a bug report?
All the best,
Dave.
_______________________________________________
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