Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: practical use of UID for USB devices
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: practical use of UID for USB devices

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

_______________________________________________ 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
 >Error -10838 calling MIDIClientCreate (From: "Marco Hinic" <email@hidden>)
 >Re: Error -10838 calling MIDIClientCreate (From: Doug Wyatt <email@hidden>)
 >Re: Error -10838 calling MIDIClientCreate (From: "Marco Hinic" <email@hidden>)
 >practical use of UID for USB devices (From: Chris Silverberg <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.