Add Device::id()

[zmerp]

This PR adds an id method to Device.

For WASAPI, the ID corresponds to the GUID of the device. On ALSA, the ID is just the device name. For now, all the other backends return an "Unimplemented" error.

The ID is useful when we want to store and load a device selection setting, and deal with devices with the same name (on Windows).

Tested on Windows 10 2004 and Ubuntu 18.04.

[Ralith]

String feels like a poor choice for this, especially in a world where USB and PCI vendor/device IDs exist. I expect Windows is the only platform where this API makes sense at all, which makes it a poor choice for an ostensibly portable abstraction.

[zmerp]

I have to admit i'm not really familiar with the platform specific APIs or audio programming in general, but here's my thoughts.

WASAPI doesn't seem to provide vendor/device IDs, only the GUID of the device. On ALSA, device and vendor IDs can be obtained with PCM::info(), but they don't seem to uniquely identify the software level devices. Software devices that correspond to different surround settings or hw/plughw have the same vendor/device/subdevice id. I also looked at the web API; MediaDeviceInfo.groupId would correspond to the (physical) device id, and MediaDeviceInfo.deviceId would correspond to the universal ID that I propose.

I understand that String is not optimal, but that seemed the best choice for being serializable and for portability across backends. We could instead use different custom structures for each backend but then they would be opaque and it doesn't make much sense if we also want to serialize them, unless we also provide a method for serializing them using a trait.

Ultimately this Device::id() API wants to be a best-effort solution for identifiability across sessions/enumeration invocations within the same backend.

[antoineradio]

Hello, I think that would be useful to get a Device::id or Device::uid storing maybe a GUID provided by the audio API (I don't know the specs of low level audio stuffs but it must exist..).

It would allow to make difference between two soundcards wearing the same name and also storing a soundcard in configuration and being able to stay ready to play among the names update and co..

Currently I'm using the name because I didn't found equivalent property in the doc.. :)

Regards,

[Ralith]

I also think this would be useful, and I've come around a bit on using String. Different platforms will have different stuff (maybe windows has a UUID, Linux could have some topological udev path) and an opaque bag of UTF-8 might be a more pleasant compromise than trying to define a complex non-exhaustive enum.

[abey79]

As I write in #922, one of the major motivating use case for this is to keep track of devices across application launches (e.g. to remember a user selection). A String containing whatever platform-specific, device-identifying content fits that bill perfectly imho.

[G2-Games]

I would really appreciate this functionality as well.