USB DACs and Linux RoonBridge -- "Device Not Found"

Roon Software Discussion Linux
1

At some point, we should attempt to solve the mystery of why a Linux box running RoonBridge can’t “find” a USB DAC plugged into it. The forum is littered with many reports of this problem, and no solutions that I could find.

Today, I plugged a Topping DX3 Pro into my Linux box:

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 0: ALC1220 Analog [ALC1220 Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: Generic [HD-Audio Generic], device 1: ALC1220 Digital [ALC1220 Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: Pro [DX3 Pro], device 0: USB Audio [USB Audio]
  Subdevices: 0/1
  Subdevice #0: subdevice #0
$

I can play to the DX3 Pro just fine, using Linux apps. But when I look at the Roon remote control, I see that it can see it – says “DX3 Pro”, right on the machine it’s plugged into:

unnamed
unnamed1029×471 37 KB

But when I enable it, I get the dreaded “Device not found” message there. I’ve tried various powerings/reboots – even restarted RoonBridge – but with no success. Looking at the RoonBridge logs, I find this:

02/25 14:32:03 Trace: [jsonserver] [192.168.3.8:60554] GOT[LL] [2] {"request":"enable_device","device_id":"hw:CARD=Pro,DEV=0","subscription_id":"25"}
02/25 14:32:03 Trace: [raat_wrap] creating new RAAT device
02/25 14:32:03 Trace: [RAAT::DX3 Pro] [info] initializing info dictionary
02/25 14:32:03 Trace: [RAAT::DX3 Pro] [info] inserting raat_version -> 1.1.38
02/25 14:32:03 Trace: [RAAT::DX3 Pro] [info] inserting protocol_version -> 3
02/25 14:32:03 Error: [raat_wrap] RAAT__OUTPUT_PLUGIN_STATUS_DEVICE_OPEN_FAILED failed: failed to initialize alsa output
02/25 14:32:03 Trace: [jsonserver] [192.168.3.8:60554] SENT [1] [nonfinal] {"status": "DeviceChanged", "device": {"error_message": "DeviceOpenFailed", "type": "alsa", "device_id": "hw:CARD=Pro,DEV=0", "config": {"unique_id": "4109b3d3-022a-43df-07a2-b3103a8c2faf", "volume": {"
02/25 14:32:03 Trace: [jsonserver] [192.168.3.8:60554] SENT [2] [nonfinal] {"status": "DeviceInitFailed"}

Over and over. As per usual, these Roon log messages don’t really tell us much about what went wrong.

This works fine when plugged into a Windows or Mac machine. But of course they aren’t using RoonBridge.

In syslog, I find this:

Feb 25 14:21:39 Tess kernel: [615033.655657] usb 1-5: new high-speed USB device number 7 using xhci_hcd
Feb 25 14:21:39 Tess kernel: [615033.835395] usb 1-5: New USB device found, idVendor=152a, idProduct=8750
Feb 25 14:21:39 Tess kernel: [615033.835398] usb 1-5: New USB device strings: Mfr=1, Product=3, SerialNumber=0
Feb 25 14:21:39 Tess kernel: [615033.835400] usb 1-5: Product: DX3 Pro
Feb 25 14:21:39 Tess kernel: [615033.835402] usb 1-5: Manufacturer: Topping
Feb 25 14:21:55 Tess kernel: [615049.352248] usb 1-5: parse_audio_format_rates_v2(): unable to find clock source (clock -110)
Feb 25 14:22:31 Tess kernel: [615085.197237] usb 1-5: cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0xa00, type = 4
Feb 25 14:22:31 Tess kernel: [615085.197244] usb 1-5: 10:0: cannot get min/max values for control 2 (id 10)
Feb 25 14:22:40 Tess systemd-udevd[488]: seq 6021 '/devices/pci0000:00/0000:00:01.3/0000:02:00.0/usb1/1-5' is taking a long time
Feb 25 14:23:02 Tess kernel: [615115.914322] usb 1-5: USB disconnect, device number 7
Feb 25 14:23:02 Tess start.sh[6846]: ALSA lib pcm_hw.c:1713:(_snd_pcm_hw_open) Invalid value for card

Over and over.

2

I finally took the step of upgrading my machine from Ubuntu 18.04 to 20.04. It fixes the problem. Of course, it could have been the many reboots I had to do :slight_smile: .

2 Likes
3

It looks like it may have been an ALSA issue that was resolved by the upgrade.

4

This happens to me as well…all the time. But in my case I’m already running Ubuntu 20.x LTS and it still happens.

If I reboot it will work again…for a little while then out of the blue will rear its ugly head for no good reason that I can see.

This is a Roon specific issue because even though Roon says it can’t find my USB DAC at the same time I can simply just play a U Tube video out via the same DAC and machine just fine.

Pretty annoying to say the least.

I’m using a Benchmark DAC3 connected to a Intel NUC via USB running Ubuntu 20.04.01 LTS and Roon 1.8 (build 814) on the Core and the Bridge

5

I’d start by blacklisting the modules for the card(s) you will likely never use … HDMI audio from your video card for example. If you must have the onboard audio/pci soundcard enable (you use it) also make sure you have a .asoundrc that list the USB DAC as the default audio.

ALSO … if you don’t have pulse installed and the current device is active, playing something from a browser for example, then Roon will not consider it a valid playback device.

6

I am getting the same error with a Chord Mojo USB DAC. When plugged, it is correctly detected as a Chord device, Roon asks me to identify it, I select Mojo and then – “device not found”. I cannot select it as an audio zone and therefore have no sound. This setup used to work a few months ago…

I’m on Archlinux. Plex or other music players have no problem whatsoever using the same DAC.

EDIT: I managed to get it working, turns out the Arch package creates a roon user who is not part of the uucp group and therefore cannot access USB devices…

EDIT2: after restarting roon I get back to the same error, so playing around with the uucp group probably was a coincidence and I do not understand why it worked that one time and now does not anymore. Going back to Roon being the only music player on my machine unable to output sound, while also being the only music player with a paying subscription.

7

I had slightly similar problem on Raspberry PI.

In that context this message really means that device is not accessible. Some other process has to be using your audio device and then Roon cannot use it exclusively. In my case it was pulseaudio.

1 Like
8

It may be that the pulseaudio is automatically switching source on connect, ie, the new plugged in device is becoming the default sound output as soon as it is attached and therefore, being grabbed by another system resource. Check if module-switch-on-connect is loaded (and/or ```
module-switch-on-port-available). If they are loaded, then try unloading and see if that works.

From you favourite terminal session…
$ pactl unload-module module-switch-on-connect
$ pactl unload-module module-switch-on-port-available

If this fixes the problem, then edit out the load commands from /etc/pulse/default.pa
This should stop the modules being loaded at boot.

I also notice in threads that people are having issues with just getting the USB DAC recognised even after reboot. Note that pulseaudio will automatically reconnect to the last used output device if available (function of module-default-device-restore). So people still finding issue with not being able to connect even after a reboot, ensure that the DAC is not the default sink prior to reboot or just unplug the DAC prior to reboot (and after changing /etc/pulse/default.pa). This should stop puseaudio from defaulting back to the DAC at reboot should it have been the default sink.

Option 2:
From the GUI (gnome), go to system settings → audio → advanced
With your DAC plugged in:

  1. Ensure that the DAC is NOT the default device select the internal speakers or something else as the default).
  2. Deselect the option to “automatically switch all running streams when a new output becomes available”
  3. For your DAC, set the profile to be “Off”

This is all assuming that you only ever want to run sound through to your DAC from the roon server or some other alsa direct service.

Warning, I do not in fact have this issue on my own system running roonserver (Ubuntu 14.04 LTS) but this is based on my frustrating experience with the way that pulseaudio and alsa interact on Debian based systems.

Edit - I have updated my Ubuntu server with my own suggestions and it has fixed an issue where my DAC had to be manually rediscovered each time it was powered on.

9

Can you just not disable Pulse audio? We do on our Centos systems at work as it causes all manor of issues with the software we run that needs audio it works fine with just Alsa.

1 Like
10

Yes, that clearly is an option

11

I have personally found the latter Linux Kernels work alot better.
5xxx+

I’m running ubuntu 21.04, no issues, my DAC has issues on Roon Rock, which runs a vastly older Kernel. I get sync/lock, but no audio playback.

Ubuntu are about to release 21.10 in a few weeks.
Should be running Kernel 5.15.
The beta is available now running Kernel 5.13?? i believe.

12

Kernels above 5xx+ seem to play ball much nicer with USB devices.

13

I have the same issue with ALSA on Arch. Everything is fine at boot, and Roon sees the USB DAC fine. But either Roon can see and use the DAC, or sound from the desktop (any application) can. Once you’ve played sound Roon is unable to connect until I restart the service and change the sound output in my desktop settings.

I see that the Roon bridge states that “We only support situations where we have direct and exclusive access to the hardware”, but is there a way to get the two playing nicely? I’ve tried messing with .asoundrc and dmix to no avail.

1 Like
14

it is possible, but it’s ugly :wink:

I got it working at some point with PulseAudio, but in the end was not happy with latency and such.

The ‘proper’ solution might be found in PipeWire, the new low-latency Linux audio solution that is capable of doing all sorts of complex audio routing, also with existing API’s (Alsa, PulseAudio, JACK).

Pretty sure PipeWire is available for Arch, so you might give that a try.

15

I’ll work on it. I have installed it, but still no sharing of ALSA. I tried setting system sounds to something other than my DAC, and then piping that output to the USB DAC in Helvum, but it doesn’t change anything. If I connect Roon to the DAC first, it doesn’t show up as available on my desktop (or visible in Helvum), and if I let the desktop play something through to the DAC then it is unavailable in Roon, regardless of whether I’ve set the DAC as the output device in settings, or done my little piping trick in Helvum. Need to learn more to see if this is doable.

16

Resurrecting this from the dead just to mention what works for me as a workaround since my last post in this thread.

When the issue pops up (about 2 times a day these days) (Device Not Found) (Ubuntu 20.x LTS) I open the Terminal and type the following command:

“pactl exit”

And like magic the problem goes away every time…until the next day at which point I rinse and repeat. Sometimes out of anger I’ll even run the command above 3 or 4 times in a row, just because it makes me feel better :expressionless:

2 Likes
17

Apparently Roon uses ALSA to speak to audio devices on Linux . Roon only support situations where they have direct and exclusive access to the hardware.

As your roon output is to the ALSA interface, then by killing pulse audio (IIRC it just restarts), you may be deallocating the device from being the default pulse audio output device. Your default system output device may have become deactivate through the pulse audio “module-suspend-on-idle” doing exactly what it is intended to so and that is to save on resource by suspending idle sinks. From the man page:

Since 0.9.11. Disconnects sinks and sources from their backend after a predetermined amount of idle time. Idle time is accumulated when the sink/source in question is not connected to any streams.

Advantages: Saves power. ALSA uses considerably more CPU cycles when pulseaudio has to send empty data to the soundcard during idle. If you don’t plan to have an active stream all the time, set the timer to a low value for best power savings.

See my post from September 2021 about ensuring that the DAC does not get grabbed by the system for some other audio output function. For example, if your system audio is output to a monitor (eg, via HDMI), if you power down the monitor, the system will search for another sink to route system audio and may grab the DAC. Powering up the monitor and issuing a “pactl end” would redirect the audio back to the monitor and free up the USB DAC sink.

If you just want to ensure that roon is the only service that uses the USB DAC, then I suggest that you remove the USB DAC from being seen by pulse audio (see the gnome commands that I listed in my Sep 21 post).

1 Like