Re: practical use of UID for USB devices
Re: practical use of UID for USB devices
- Subject: Re: practical use of UID for USB devices
- From: Jeff Moore <email@hidden>
- Date: Thu, 29 Sep 2005 11:49:37 -0700
On Sep 29, 2005, at 11:25 AM, Chris Silverberg wrote:
Hi folks,
I work on a VoIP application and use CoreAudio API's for device
capture and selection. In our preferences window, the user can
select their input and output devices, and I save the user's
selection by storing the kAudioDevicePropertyDeviceUID property.
This works pretty well, but there is a problem.
For USB devices, the UID varies based on which USB port the user
selects. For example, if I connect my Plantronics headset to my
PowerBook, depending on which port I plug into, I will get one of
the following UIDs:
AppleUSBAudioEngine:Plantronics:Plantronics headset:1b100000:2
AppleUSBAudioEngine:Plantronics:Plantronics headset:3b100000:2
Clearly the second to last component of the string identifies the
USB port. Although I'm sure this is useful in certain scenarios,
it pretty much prevents the software from being able to save the
user's selected device in a reliable mannor. With two USB ports on
the side of a PowerBook, it's going to be somewhat random which
port a user will use to plug in.
This is sadly true. The reason why is that most USB devices don't
have any information with which the USB audio class driver can
differentiate two instances of the same device from each other except
by using the USB network topology.
Tthe USB audio class actually does have the capacity for device
manufacturers to provide this information through a serial number
property. Unfortunately, we can't rely on that because we have seen
devices that have the same value for this property for every instance
of the device and we're back to topology to differentiate them.
So, does anyone have any advice on how to handle this? Two choices
come to mind... first, I could use
kAudioDevicePropertyDeviceNameCFString instead of the UID which
would probably solve the problem in most or all cases. Secondly, I
could try to match the UID intelligently so that I ignore the
difference between USB ports, but that seems a bit messy and
subject to break in the future.
Interpreting the contents of a UID string isn't something we
encourage. UIDs should be regarded as black boxes.
The right thing to do is to first use the device UID
(kAudioDevicePropertyDeviceUID) to locate your preferred device. If
that fails, then you should fall back to looking for a device that
has the same model UID (kAudioDevicePropertyModelUID). If that also
fails, then you should pick whatever device your app deems most
appropriate with a strong preference for the default device
(kAudioHardwarePropertyDefaultInputDevice or
kAudioHardwarePropertyDefaultOutputDevice as appropriate).
Is this simply a design flaw with the UID property?
It is a flaw with how most USB audio class devices are implemented.
The system has to make due with what it has on hand.
--
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