When I enable my audio device it’s stuck in “Enabling” state.
I’m using an ASUS X670E-F GAMING WIFI motherboard, and this is with both the bundled audio driver and with the Windows default audio driver.
Surprisingly enough, this also happens with my Yeti Blue Microphone which works fine when connected to another machine. So this, to me, seems to be motherboard-related. I’m using Windows 11 x64 and an AMD Ryzen 7 7800X3D. The built-in soundcard shows up as Realtek USB 2.0 Audio, even though it’s built into the motherboard. This is the Windows USB identifier: USB\VID_0B05&PID_1A52&MI_00\9&D60B9F&0&0000
Roon Core Platform
Linux (NAS/SonicTransporter/Antipodes/Ubuntu/etc.)
Linux Core Type
Ubuntu
Roon Core Specifications
First generation Intel i7 system from around 2010. Has worked fine with Roon until I upgraded my listening PC. Still works fine with my other Roon client devices (like Bluesound) and other Linux Roon Bridges.
Connected Audio Devices
Realtek USB 2.0 Audio (onboard, see above) and Blue Yeti (USB)
Home Network Details
Both my listening PC and my Roon core is connected using gigabit ethernet.
Hi @robin1,
Thanks for your patience while we worked through the queue. I found this thread which seems to relate to your issue. Audio devices stuck on 'Enabling' status in Roon Audio setup - #5 by ColdOnes. The customer in this thread was able to resolve their issue by uninstalling and reinstalling Roon bridge. Let me know if this works for you.
I’m not using Roon Bridge on any of the problematic devices. They clients are using Roon for Windows, and the server is running Roon Server for Linux (on Ubuntu 20.04). I noticed several times there is a reference to the word “bridge” in the referenced forum topic. Are they talking about a network (OSI layer 3) bridge? If so, I have those setup on both my client machines (because I also use Hyper-V for virtualization), and I use a bridge on my Linux machine (also because I use KVM virtualization).
Uninstalling these (software) network bridges is not something I can easily do (especially on the server), as it’ll impact a lot of other software running there. Can I configure Roon (clients and servers) to only bind to a specific interface? I’m not sure, but this could also be affected by me running Tailscale on all machines in my network.
Hi @robin1,
After speaking with the rest of the team. I have two things I would like you to try.
If you disable and remove the ASIO device, does the issue still occur?
Does the same issue occur if you disable all devices, and connect one audio device to your server directly?
Refreshing your RAAT Server database may also help here. You can generate a new RAATServer instance on your device by following these instructions, but please be aware that this will reset your Roon Settings → Audio Tab to factory settings and I would advise making a backup of any custom DSP settings you have:
Rename the “RAATServer” folder to “RAATServer_old”
Restart the Roon App to generate a new RAATServer folder
Lastly, I would note that the use of virtual machines as well as VPNs falls outside of the scope of support, unfortunately. You’ll need to disable both while we troubleshoot. Thanks for your understanding!
I don’t have any ASIO devices in my list, so not sure what you’re referring to.
I only have this issue with my Windows 11 machines with Realtek audio devices. My Bluesound and Linux-based Roon bridges have no issues playing back sound. That also includes the analog output from my Linux Roon Server.
I tried your approach with deleting the RAATServer directory on the Roon Windows client, and at first glance it had no effect. But after trying to disable Tailscale and twiddling with my Hyper-V settings and making sure there were no lingering issues with the network, I started the server and windows client again, and I was able to get a list of all my audio devices connected to my local Roon Windows client, but I had all of them listed three times! So in total I had 12 audio devices listed. I tried to enable all of them one-by-one, and it seems most of them were just stuck in the “enabling” state, but the last ones actually got enabled! My guess is that since my Windows client and server are multi-homed with multiple network interfaces, and Roon is binding to all of the interfaces, it detects all of the audio devices, but multiplies it for each listening network interface. And it’s only one network interface that actually works of the three. I haven’t gotten to the bottom of which interface works and which doesn’t. If you had made it possible to specify which network interface you’d like to bind to (in some advanced configuration somewhere) I’m sure these kinds of issues could be avoided for people having complex network configurations.
There are no virtual machines involved in my Roon setup. The Roon server is run on bare-metal and the Roon Windows client is also running on bare-metal. The VMs I mentioned are running along-side the Roon application on the same machines and shouldn’t have any impact on its behavior.
I’ve actually tried both the ASUS-provided soundcard drivers (the ones you refer to above) and the built-in Windows Update drivers, and they behave exactly the same. IE the sound device is stuck in “enabling” state.
Are the outputs that you were able to enable working, and you were able to hear audio playback through them?
Yes, Roon does bind with all network interfaces, but I haven’t seen multiples of audio interfaces before yet, even when users had quite a lot of interfaces enabled.
What happens if you try to completely uninstall the Realtek driver in Windows Add or Remove Programs and let Windows install the default audio drivers?
After a lot of debugging it turns out that the issue was not related to the audio drivers, but networking.
Since I was using Hyper-V and had set up the local Ethernet adapter as a bridge (vEthernet (Bridge Ethernet)) so that I could use the adapter both for normal traffic and virtual machine traffic. It turns out that the bridge network adapter was set to a “Public” network profile and Roon was not allowing incoming traffic on the “Public” network profile, only the “Private” network profile.
To solve the issue, I opened up a PowerShell terminal and ran the command Get-NetConnectionProfile. That showed that the network was set to public profile.
I then ran the command Set-NetConnectionProfile -InterfaceIndex 18 -NetworkCategory Private to change the network profile to “Private” for the virtual ethernet interface.
