Re: Two same name audio device
Re: Two same name audio device
- Subject: Re: Two same name audio device
- From: Michael Thornburgh <email@hidden>
- Date: Thu, 10 Jun 2004 13:52:23 -0700
Timo: i don't think you need to go looking in the IORegistry for what
you need -- kAudioDevicePropertyDeviceUID should be sufficient to get
the UID of an audio device. and you can look up a device by its UID
with kAudioHardwarePropertyDeviceForUID.
regarding the input vs. output sides of (for example) a USB audio
device, check out kAudioDevicePropertyRelatedDevices to help you group
the right ones together without looking inside the UID (which, as Jeff
says, is bad and wrong).
for a simple algorithm that groups all related devices together using
that property, see the implementation of +[MTCoreAudioDevice
allDevicesByRelation] in MTCoreAudio. :) you can use CFSets to keep
track, if you're not using objective-c.
-mike
On Jun 10, 2004, at 12:35 PM, Jeff Moore wrote:
The crux of this statement is true. Namely, the way to differentiate
amongst devices is through it's UID. However, just looking at the last
segment of the UID to tell the input from the output is flawed in at
least two ways.
The first problem is that not all drivers construct their unique IDs
the same. For example, your driver might not override
getLocalUniqueID(), but there could be others that do. Plus, there
will be drivers that override the whole process so that this
construction technique doesn't apply at all (not to mention drivers
that aren't based on IOAudio in the first place).
It boils down to the fact that the UID of a device is a black box.
It's contents are private to the driver that manages the device it
belongs to. Apps should never write code that depends on the actual
content of a UID.
The other problem is that the UID doesn't tell you how to
differentiate the AudioDevice that represents the input side of a USB
device from the AudioDevice that represents the output side of the USB
device. Even for drivers that use the construction technique you
describe, there is no way to guarantee for every device that the
engine that corresponds to the first index is always going to be the
input engine. The fact is, this is at the mercy of the enumeration
mechanisms of IOKit and the ordering of the interfaces in the firmware
of the USB device. So one can't say definitively that a UID that ends
in ":1" is always the output device.
So given that you tell one device from another, in general, with the
UID, to know the input device from the output device, you need to (as
Mr. Duncan pointed out) use the actual stream configuration of the
device.
As a final comment I would also add that just because a device is a
USB device doesn't always mean that the input section and output
section are always presented as separate devices. This is only true
for devices that are compliant with the USB Audio class spec and use
the class driver provided with the system. The reason for this is that
the USB Audio class spec clocks the two sections separately from each
other. They can each have different sample rates even. This makes them
independent with regard to timing which is how the HAL delineates
audio devices.
On Jun 10, 2004, at 8:52 AM, Kris Daniel wrote:
On Jun 10, 2004, at 4:56 AM, Timo Rantala wrote:
I have two similar usb audio device.
When I read "AudioDevicePropertyDeviceName",
I get two same name.
How can I know, which one is which one ?????
( is there any special ID or something )
Yes, there is. Here's a clip from
http://developer.apple.com/documentation/ReleaseNotes/Darwin/
IOAudioFamily.html that describes the IDs you want to look for:
--quote--
b" Added support for a global unique ID to be assigned to each
IOAudioEngine to allow each engine to be identified across reboots
and detach/re-attach operations.
b& New IOAudioEngine functions: getGlobalUniqueID and
getLocalUniqueID.
b& getGlobalUniqueID by default generates a unique ID string by
concatenating the class name, the location of
audioDevice->getProvider (which ls the location within the provider's
bus) and the result of getLocalUniqueID.
b& getLocalUniqueID needs to generate a scoped ID that is local to
the device. The default implementation returns an index based on the
order that the IOAudioEngine was added to the IOAudioDevice. If that
isn't sufficient to guarantee uniqueness for the engine, this should
be overridden to provide a better ID. A case where this is necessary
is the USB audio driver. Since a single driver/class may drive
different pieces of hardware that could be plugged into the same port
(and hence return the same location), it needs to provide another
piece of information that is unique to each device.
b" Added IOAudioEngine::setDescription to allow a custom
description to be set on each IOAudioEngine.
--quote--
If you need to get the ID from the IORegistry, find the
IOAudioEngine's entry and get the IOAudioEngineGlobalUniqueID
property.
There is, however, a problem that you'll run into with Audio MIDI
Setup (version 2.0): if two (or more) devices provide the same name,
(which happens when identical devices are plugged in over USB), Audio
MIDI Setup will only display the name once in the drop-down menus for
audio device selection, even if the devices have different
GlobalUniqueIDs. This strikes me as a bug in Audio MIDI Setup. I've
only seen it happen with devices that I'm writing the driver for, so
it's possible I'm doing something wrong.
I'm overriding getGlobalUniqueID and creating a string that reads
like "<company> <product>: <serial number>". At the moment, I only
have one audio engine per device instance, so I didn't feel a need to
override the default implementation of getLocalUniqueID.
Thanks,
Kris Daniel
_______________________________________________
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.
_______________________________________________
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.