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: Jeff Moore <email@hidden>
- Date: Fri, 8 Nov 2002 11:54:09 -0800
No there isn't any way to get the IOAudioDevice attached to a
particular AudioDeviceID. It's something I've thought about, but
nothing is currently on tap to make it happen.
Since you mentioned it as such an important part of your
implementation, I have to caution you that relying on the contents of a
UID will fail. The contents of a UID are private. There are no
guarantees that any references to an IOAudioDevice will ever be in that
string. The contents can be anything. For instance, the string can just
be "Fred" and things would be fine in the system.
Also, there are no guarantees that a device you are talking to with the
HAL will even have an IOAudioDevice object (or any other IOKit object)
associated with it in the first place. I strongly recommend that you
abandon the need to map AudioDeviceIDs back to their IOKit
implementations. It will break in the future.
Finally, if you really care that much, there's nothing stopping you
from looking in the IORegistry yourself. That's where the HAL gets the
information, including the UID, in the first place.
On Thursday, November 7, 2002, at 05:44 PM, Shaun Wexler wrote:
Is there a preferred or accepted method of detecting the actual
IOAudioDevice objects from user space, rather than using the returned
HAL
CoreAudioDevice (ID) objects? I ended up parsing the DeviceUID
returned by
HAL to determine devices, and retain matching dictionaries. I have
wrapped
HAL with my own classes, similar to Michael T9s framework (thanks MT
for the
nice ref materials, BTW), and use AudioChannel objects as my models
for I/O,
which keep all info necessary to maintain a persistent state, further
abstracting the hardware from the user. An AudioChannel maintains a
connection to its client(s), and represents one channel of an audio
stream.
One AudioManager object owns and maintains all Audio_xxxx objects. In
other
words, if an physical I/O device is removed (USB cable is unplugged,
etc),
I/O stops but the AudioChannels persist and their clients don9t lose
their
configuration. When the removed device (or ANY newly added compatible
device) again becomes available, it is auto-configured and resumes
operation
with no user intervention, to the point of allowing different devices
to
exchange I/O duties, or simply remembering a device between a USB/FW
port
move. My implementation works very well, but I want to ensure future
compatibility...
I guess a feature request is in order: we need a method of enumerating
actual hardware devices (ie IOAudioDevice) rather than just the
CoreAudioDevice (ie IOAudioEngine) objects returned by HAL, even if
it9s
just a CFArray of AudioDeviceID.
How is it done in Apple9s Audio MIDI Setup?
--
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.