-
Notifications
You must be signed in to change notification settings - Fork 322
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
Comments
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. |
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?
And FYI this works fine for us, two soundcard, two instances. |
I am also using multiple RTAudio instances and upgrading to latest version breaks the device discovery. Can you share your patch? |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: