Re: Identification of IOAudioDevice from HAL client app
Re: Identification of IOAudioDevice from HAL client app
- Subject: Re: Identification of IOAudioDevice from HAL client app
- From: Shaun Wexler <email@hidden>
- Date: Mon, 11 Nov 2002 14:05:57 -0800
On 11/11/02 1:21 PM, "Jeff Moore" <email@hidden> wrote:
>
I don't like this. This means that we need to define more data
>
structures and more infrastructure to support what I consider a pretty
>
sketchy situation.
Yep, if there's a more reliable way, I'm all for it. I do really feel there
is a need for the array of grouped AudioDeviceID, though. That alone would
be worth Apple adding a new feature, as all developers could utilize it.
>
Like I said, you can sniff the registry yourself if it matters that
>
much. Given that the GUID string is also in the registry, it makes it
>
trivial to map the registry entry back to the AudioDeviceID.
I shall rethink and rework my code, using the IORegistry rather than parsing
the UID. Thanks.
>
AudioDeviceIDs are meant to be transient. Device GUIDs are the things
>
you should be using to represent a device persistently. In my own apps
>
(and indeed in the HAL itself) as long as I match GUIDs, I never have
>
trouble with matching up devices with what I was using previously.
>
That's what they are there for.
I use the UID as keys for all my ConfigDicts, but consider this scenario: a
user has a USBAudio device (let's say 2-in, 2-out), and is outputting stereo
audio for a live event. Accidentally, the USB cable is pulled out of his
computer, and the audio ceases. He quickly plugs it back in, but to the "B"
port instead of the "A" port it was formerly connected to. Nothing. App
needs reconfigured and the show is still waiting. He unplugs it again and
reinserts it into the "A" port. System and Default Audio Devices are then
reassumed by HAL, but his player app needs reconfigured, as the
AudioDeviceID is different, though it still has the same UID, but new
streams must be prepared. Can most apps handle this situation? My guess is
no.
>
One could argue that if you are trying to reconcile a new device's
>
capabilities with the capabilities of another device that is no longer
>
there for the purposes of remapping IO, you need to look at a lot more
>
info then just how it was attached to the system and what other devices
>
it might be physically attached to. This would seem to mean absolutely
>
nothing if I were trying to do what you are doing.
...the show must go on. What if the aforementioned USBAudio device is
physically disabled, stolen, broken, etc? There is a backup device
available, which has similar capabilities to the dead one, so by quickly
reconfiguring its I/O, my app continues the show. This feature is optional
via pref's, of course, but is very valuable to my user base.
>
I have to admit I really have trouble with visualizing what you are
>
talking about and what sort of advantage it has for your users.
>
Personally, I would hate using a piece of software that thought it knew
>
more than I did about how I want to route audio in my system when I
>
move it from studio to studio.
You must also consider that not all uses of audio I/O are within the walls
of a studio, and not all users need/want or are able to utilize a tighter or
lower level of control over their devices.
PLEASE consider adding the AudioDeviceID matching array property to the HAL.
Sincerely,
--
Shaun Wexler
http://www.macfoh.com
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.