Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lp35 opened this issue Sep 13, 2022 · 4 comments
Open

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

lp35 opened this issue Sep 13, 2022 · 4 comments

Comments

@lp35
Copy link
Contributor

lp35 commented Sep 13, 2022

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
Copy link
Contributor

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
Copy link

ImKyra commented Oct 6, 2023

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
Copy link

paulh002 commented Nov 9, 2023

AlsaAPI

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

@ImKyra
Copy link

ImKyra commented Nov 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants