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: Mon, 3 Oct 2005 11:35:33 -0700
On Oct 2, 2005, at 5:05 PM, Herbie Robinson wrote:
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.
You should make the real serial number available somehow so that
the system and applications can correctly support devices that
actually are implemented properly.
That last part of the sentence is a big if given what we have seen of
the devices on the market.
Besides, from an application's point of view, it's the UID that is
important, not some random property in the firmware of a device that
may or may not have the information to identify a device. It is the
driver's job to take whatever information they have about a device
and construct a UID that can be a persistent token for identifying
that specific device across processes and across boots on a
particular system. It turns out to be the case that for some devices
there just plain isn't enough information to do this 100% reliably.
The driver has to make the best of what it has.
It hardly seems fair to penalize properly implemented devices so
that more than one incorrectly implemented device can be
supported. Especially considering that properly implemented
devices are more likely to be the high quality ones that are most
likely to be used in multiple device combinations.
Given that the vast majority of class compliant devices we have seen
do not provide this property in the first place and most of the ones
that do implement it incorrectly, I don't see that this property is
any more useful when present than not having it at all. The
information is _unreliable_ both in definition and in practice.
IMHO, this is a specification failure with USB. We do not have such
problems on FireWire where the spec requires each device to be
individually identifiable no matter how it is connected to the system.
How about using the serial number as the unique id as long as there
isn't more than one instance of the same serial number on the
system and concatenating the topology location if there is more
then one device from the same manufacturer.
That or if you see two devices with the same serial number, ignore
the second one...
Not sure how that makes this situation any better. Seems to me all it
does is make the UID string longer before you have to add
disambiguating information to it that is related to how the device is
connected to the system.
Since I have yet to see a user that was pleased with the system
ignoring a device that she has plugged in, I dare say that we would
be remiss in our duties as system developers if we implemented
something that did that.
At any rate, the UIDs are the best the driver can make them under the
circumstances. They aren't perfect and, by definition, cannot be
perfect. Knowing this ahead of time allows you, the app developer, to
be prepared and to deal with the fall out in a way that makes sense
in your app.
--
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