Add more fields to RtAudio::DeviceInfo / improve device ID on ALSA

thestk / rtaudio

A set of C++ classes that provide a common API for realtime audio input/output across Linux (native ALSA, JACK, PulseAudio and OSS), Macintosh OS X (CoreAudio and JACK), and Windows (DirectSound, ASIO, and WASAPI) operating systems.

Other

1.49k stars 318 forks source link

Add more fields to RtAudio::DeviceInfo / improve device ID on ALSA #368

Open lp35 opened 2 years ago

lp35 commented 2 years ago

Hi,

I just tested the new implementation with the unique ID in the API.

AFAIK, the RTApi is not thread safe. In our application, we have currently a audio deice manager, than scan periodically for new/incoming devices, and a "device" that is another instance of RtAPI object.

That said, IDs of both API might differ. So it is needed either:

Having a device ID that is "static" between all instances of RtAudio
Having an extra field, called "deviceName" or "devicePath" or changed the ID in string. On Linux with Alsa, we have the guarantee that the path of the device is unique (e.g hw:0), so this shall be used as a "unique ID".
Rename "name" path in "pretty name" and use name as the hw path.

To survive IDs across reboots, we can create a hashed value of "pretty device name" in addition of "hw path".

What do you think about that?

Cheers.

garyscavone commented 1 year ago

I'm not sure why I didn't respond to this earlier. I am open to the idea of having device IDs be static. In fact, the deviceList_ could potentially be static. However, it seems like it could be tricky to program. One thing I would recommend is to not use two different instances of RtAudio. I haven't done a lot of testing but I think you could use a single instance to run a stream and still be able to periodically scan for device changes. And having ID persistence across reboots also seems tricky ... I would probably just use the device names but there is the possibility on non-unique names reported by different APIs.

ImKyra commented 11 months ago

Hey I had the same issue as we need to provide static configuration for multiple devices so I patched the library to have an "HWID". For now it works for Pulse, Alsa, WASAPI and I'm trying to get DirectSound and ASIO. I can't test OSX as I don't have any access to a mac.

AlsaAPI provides the hardware path : hw:X,X

PulseAPI provides the sink/source path (alsa_input.usb-Sennheiser_EPOS_headset_w_PTT45_USB_ACTPTT_02044_00003-00.mono-fallback) which looks to be enough to properly identify a unique device

WASAPI has a kind of UUID but it looks unique to each device, even from the same manufacturer (ex: {0.0.1.00000000}.{d3dd3ff5-ea0b-42ba-9120-edb30b784e91} )

For the rest it still under development so I'm still trying to figure out what would be the best identifier.

Would you be interested in such update?

One thing I would recommend is to not use two different instances of RtAudio

And FYI this works fine for us, two soundcard, two instances.

paulh002 commented 10 months ago

AlsaAPI

I am also using multiple RTAudio instances and upgrading to latest version breaks the device discovery. Can you share your patch?

ImKyra commented 10 months ago

As soon as I can, but it lacks Windows testing and OSX support. Tell me if you're in a hurry for it maybe I can mail you the diff or something.