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: Jeff Moore <email@hidden>
- Date: Wed, 20 Aug 2008 09:08:09 -0700
I think I mentioned it before, but what you are running into is
definitely a bug in the HAL (I'm sure you realized that =). There
really isn't anything more you can do to work around it than what you
are already doing.
On Aug 20, 2008, at 7:10 AM, Dave Addey wrote:
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
--
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