Removable device identification

I’ve been thinking about removable device identification and I think we should decide on a scheme for identifying removable devices in general as this isn’t a problem specific to usb audio.

When a device is registered with DeviceFS the name used is a machine id – ie it is a name generated by the machine either using an allocated name which uniquely identifies the device on the machine or a name generated from an allocated name. The problem is that for removable devices the machine id is generated at the point of insertion of the device so the id may change the next time you switch on the machine or if you unplug the device and plug it back in.

So what is needed is an id generated by the device. Unfortunately not all removable devices have serial numbers – usb audio deviced don’t. So the option is to

1) Accept the fact that removable devices can’t be used for configuration of the machine as their machine id may change.
2) Do the best we can with the information available from the device and create a device id based on that information.

So what information can be used to generate a device_id. Generally it falls into 3 categories:

1) use the devices serial number
2) Information from the device itself. For USB this could be vendor/product id and firmware version.
3) Information from the machine about the device – a location id. For USB this could be the location on the USB bus that the device is plugged in.

Obviously if a device has a reliable serial number we use that. I say reliable because generally whether or not a devices have serial numbers depends on the device class usb hard discs do usb audio devices don’t, but I have seen devices in device classes where I wouldn’t expect a serial number with a serial number but it has been something silly like ‘1’ so if a device class generally doesn’t use serial numbers any serial number will be ignored – though you could do a silly number test and ignore any serial numbers less than say 8 characters.

Just using (2) as a device id has the problem that if you use 2 identical devices the device id will be identical.

Using just (3) as a device id has the problem that you can’t change where it is plugged in without reconfiguring and it doesn’t tell you that the device connected is the at least identical to the one expected. For example you have an audio usb device plugged in and it has an id corresponding to its location. If you then change the device at that location to another audio device it will have the same id as the audio device you had plugged in previously so the system won’t know that it is different.

The best solution I can think of is to combine 2 and 3 like this – and I’d be interested in any alternatives.

We makeup a complete device_id like this.

<machine_id_root>_<device_id>_<location_id>

machine_id_root would be the devicefs registered name – the number on the end. So the root of serial2 is serial. An usb audio device with a DeviceFS registered name of AudioOut23 would have an id like this.

AudioOut_123412341234_123456789ABCD

You then add a swi to DeviceFS to get the registered name from this device_id and vice versa

Reading the device id

To get the device_id from the registered_name we add a swi to devicefs

SYS “DeviceFS_GetDeviceId”, registered_name, buffer, buffer_len

DeviceFS reserves a ‘DeviceFS_ReadDeviceID’ reason code and calls it like this

SYS "DeviceFS_CallDevice", DeviceFS_ReadDeviceID, registered_name, found, buffer, buffer_len TO ,,found,,buffer_len

found is set to 0 when called and gets changed to 1 if the device responds. This takes care of devices that don’t know about the DeviceFS_ReadDeviceID reason code. Devices that don’t respond are given a device_id the same as the registered_name.

Reading the registered name

To get the registered name from the device_id we add the swi

SYS "DeviceFS_GetRegisteredName, device_id, buffer, buffer_len, TO ,,buffer_len

DeviceFS then extracts the root of the id – AudioOut if the id is AudioOut_123412341234_123456789ABCD – and enumerates only audioout registered names. It uses DeviceFS_GetDeviceId to look for a match. But it looks in 2 passes. In the first pass it looks for AudioOut_123412341234_ If it finds only 1 match it returns the registered name for the match. If there is more than one match it does another pass and matches the full id.

This means if we store the device id for configuration purposes – or in a program for that matter. The device will be matched wherever it is plugged in if there isn’t an identical device and where it is located if there is an identical device. If the device part is really unique it will work perfectly otherwise there are ways of fooling the system by juggling identical devices.

This allows you to save the device_id ,for configuration purposes, and convert it back to a registered devicefs id for everyday use.

Any thoughts?

Edit:

As always as you press post another thought comes into your head.

It’s not good enough for the made up device_id part of the full id to consist (in the case of usb) of just vendor/product/version information as the same device can have multiple registrations with DeviceFS the device_id part would have to include the interface and alternate numbers used.

That looks good to me.

There is one problem, which is that if you two ‘identical’ devices (e.g. only the location differs), configure them for use, and then remove one of the devices then both of the device IDs which were generated during the configuration phase will now map to the same device, which could then result in both sets of configuration data being applied to the one device. But I can’t think of a direct way of solving this problem – it’s just something programmers will have to be aware of. E.g. rather than using *commands to configure settings, use a configuration file, so that the software can read in all the settings and then work out which devices are and aren’t present.

Yes without a proper id you can’t make it foolproof.

Not sure it’s relevant here as I don’t understand all that is being doscussed. However…

ALSA provides more than one way of specifying a device. One way is by the ‘name’ given by the device when queried. Which allows you to find the device even if you’ve rearranged your cards/devices. The other is by ‘number’ (of the order in which the OS ‘found’ them at startup) which lets you use multiple devices that are ‘identical’. Either way has a blind spot. But the user can choose which approach to use for a given device they want. In the absence of ensuring every example of every device coming off every production line is unique I guess this comes down to “there is always a blind spot” so you have to choose where to put it. :-)

Jim