Roon Bridge with DietPi on RPi4 Beginners Question

Hi there,
when I install the Roon Bridge via DietPi, Roon can find my attached DAC (REM ADI-2 DAC) and everything works nicely.
But when I turn power from the RPi4 off and on, Roon is no longer able to find the RPi4/DAC.
Is the Roon bridge not automatically started after boot up?

I can ping the RPi4 and can connect to the RPi4 via putty, so RPi4 is definitly up and running.

It is my experience that with some DACs the order that things turn on is important. How does it work if you power the RPi on before the DAC?

Unfortunately the same, Roon is not showing the bridge or the DAC.

Like John said already I have seen this before as well. If I turned my DAC off I often had to reboot my Pi.
I think it is dependent on the DAC, but if I rebooted the Pi it all came back up fine.

That may be the same problem I experienced on plain Raspberry PI OS:

2 Likes

Thanks, I will check what happens when I keep the RPi4 running and switch off and on the DAC.

@Piotr: I think my problem is a bit different. The DAC never shows up again, even with rescan, nor does it appear as inactive. But I can try your solution, if even I do not know anything what I am doing, as I am a complete unix naive person.

P. S. I tried some status check on the Pi and there it looked as if the roon bridge was startet/Running.
So could it be a network related issue?

If you don’t see Roon Bridge under Settings–>About then probably yes.

Maybe try Ropieee, once setup it is essentially plug and play.

The same with VitOS - seamless installation and operation.

Thanks maybe I will try this.
I thought, DietPi would be the plug and play aproach. :slight_smile:

I’m using DietPi with an RME ADI-2 and Raspi 4b. I leave the pi on all of the time so thats different from your use case. I haven’t had any problems with DietPi. The DAC disappears from Roon when I power the DAC off, as it should, and comes back when powered back on. I can try experimenting to see if I can replicate the problem you’re seeing with your use case.

1 Like

Thanks.
I am pretty sure it should work to switch of the Pi and turn it on again and everything should work right away.
I would have asked in the DietPi Forum, but this whole Unix stuff is way to complicated for me.

Maybe not. Without diving into too much detail…

ALSA is the sound framework inside of Linux. Roon Bridge looks for hardware devices that ALSA has found. If the hardware device is compatible with Roon then it shows in Settings → Audio.

USB audio devices (Class 1) negotiate their capabilities (channels, resolution, bit depth, name, id, etc.) and ALSA is responsible for this negotiation. Only after this completes is the audio device assigned a hardware ID by Alsa and then Roon Bridge finds this and that’s your USB DAC in Roon.

The opposite is also true. When you power off your DAC Alsa detects this and removes the hardware device. Roon Bridge notices it leaves the lists and removes it from Settings.

Now, the problem is, you’ve got a lot of moving parts that have to occur in a specific order but are not always stable. If you power down the DAC then power it back up… Linux needs to see the new USB attach, Alsa has to negotiate capabilities and add the hardware device, and Roon Bridge needs to see the device and realize its the same one you’ve already activated (or it could land in settings waiting for you to activate it).

Some DACs work just fine to power down / power up all day long with Alsa. Others maybe not. To troubleshoot you’d be troubleshooting Alsa (aplay -L). You may have better luck with another distribution but since they all rely on the same things probably not. However, I think I made this statement before and someone proved by wrong when they loaded Ropieee and it worked perfect after having issues with another distro. Worth a try. Most of my DACs I leave powered on. The one DAC I do power off / on the Pi (dietpi) stays on and the DAC comes back just fine. So, this may be specific to the RME and dietpi.

1 Like

Thanks.
I think, I would like to stick to DietPi, as I can install NAA protocol for the HQPlayer, which I think is not possible with Ropieee.
Fastest solution: I can let the Pi running, that is not a problem. :slight_smile:
So power saving is not possible here, not that of a big deal.

Btw: Same behaviour with the DAC Magic, which gets its power from the PI, so it is not DAC related.

Just in case you would like to try ropieee… ropieeeXL has the NAA.

2 Likes

Just installed Ropieee XL, works like a charm.

Problem solved. :grinning:

6 Likes

I tried to replicate your scenario. I did unplugged the raspi and plugged it back in and my RME ADI-2 DAC showed just fine in Roon. I also did a command line reboot (much friendlier than pulling the plug) and the RME ADI-2 was seen in Roon too. I’m running DietPi v7.5.2. So no problems like you described in my configuration.

I see below that you’ve solved the problem with Ropieee. Also a good choice. If you run Ropieee long-term then consider donating to the author if you haven’t done so already. That’s a quality product that’s well supported. I run that on my main streamer with the official raspi display. I currently have a streamer on RopieeeXL, one on DietPi, and two on HiFiBerry OS. All work just fine with no hiccups, crashes, or other things unexpected.

-Doug

2 Likes

Thanks for testing this.
I think my problem was very strange and difficult to solve. I ask others with DietPi and no one had my problem.

I will definitely donate to Ropieee as it brought me very much nearer to the decision to use Roon (and to let go my beloved LMS) and if I can afford Roon I can definitely donate to Ropieee. :wink:
Second point for Roon which convinced me, was that it is easy peasy to still use my SBTs. :slight_smile:

3 Likes

Does restarting the Roon Bridge service solve it? Probably starting it later at boot helps. Also there are systemd targets which we could use to define an order and dependency on the actual USB device for bringing up ALSA mixer settings and then the Roon Bridge service.

I’ll have a look into this.

@Daiyama
When you face this issue again, could you paste the output of the following command so that I can check the order in which services, targets and devices are brought up:

journalctl