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

Unable to set specific ASIO device for capture #30

Open
bradisbell opened this issue Jun 19, 2022 · 2 comments
Open

Unable to set specific ASIO device for capture #30

bradisbell opened this issue Jun 19, 2022 · 2 comments

Comments

@bradisbell
Copy link

When using the windows-asio API, it seems to ignore what deviceId I set when constructing the audio stream. It always picks a device that I don't have plugged in:

Error: RtApiAsio::probeDeviceOpen: error (Hardware input or output is not present or available.) initializing driver (ASIO 2.0 - ESI U24XL).

How can I solve this?

@marcelblum
Copy link
Contributor

I see this occasionally too, typically on older computers that have had many different ASIO drivers installed & uninstalled over the years. Seems to be some kind of device id mismatch between what RtAudio reports from getDevices() and actual. Usually if you experiment with incrementing or decrementing the device id by 1 the desired device can be selected but it requires some trial and error. I'm not sure if it's a bug in RtAudio, or some corruption to ASIO-related registry entries that happens on systems with lots of ASIO devices, or just buggy ASIO drivers. I've noticed that with some older ASIO devices, apps will list them as selectable even when they are not plugged in. You can also try messing with the ASIO entries in your registry and deleting remnants of old ASIO drivers for devices you don't need (https://helpcenter.steinberg.de/hc/en-us/articles/206633450-How-to-delete-old-ASIO-device-entries). I've usually been able to get around this problem by some combination of uninstalling older unneeded ASIO drivers or actually plugging in the ghost device which seems to make the system happy. No catch all solution to offer unfortunately but it would be great if it could be fixed in RtAudio.

@marcelblum
Copy link
Contributor

I think this problem has been resolved with the latest version of RtAudio contained in latest Audify release 1.8.1. RtAudio's device probing was refactored and seems like it was made more tolerant of ASIO quirks like this. It's hard to confirm definitively but I don't see this error at all any more with 1.8.1. @bradisbell I wonder if you're still getting this problem in your setup?

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

2 participants