With Alpine linux on the host, Roon cannot access /dev/snd with the provided container run command

[rubin55]

I've set up a RP3+ with docker and am trying to run your rather excellent container on it. It starts up and stays running, but I'm seeing two Warn messages related to get lock file path and after the RAATServer start, I see a Not Running (.o) message that I can't place.

The docker host is running the latest version of Alpine (3.12.x, with Linux 5.4.x), with Docker 19.03.x.

Output from stdout:

allo:# docker run --net host --name bridge --read-only --cap-drop ALL --group-add audio --device /dev/snd --rm dubodubonduponey/roon-bridge
00:00:00.024 Warn:  get lock file path: /tmp/.rnbgem2000-
00:00:00.579 Trace: [childprocess] using unix child process
Initializing
00:00:00.877 Info:  Starting /boot/bin/RoonBridge/Bridge/RoonBridgeHelper
00:00:00.936 Info:  ConnectOrStartAndWaitForExit RAATServer, path: /boot/bin/RoonBridge/Bridge/RAATServer
Not Running (.o)
00:00:00.056 Warn:  get lock file path: /tmp/.rnbhgem2000-
Running

Can you point me in the right direction?

[rubin55]

I've checked within the image (installed procps first to have a look-see) to see if all processes are running:

  PID TTY      STAT   TIME COMMAND
    1 ?        Ssl    0:05 RoonBridge --debug --gc=sgen --server RoonBridge.exe
   18 ?        Sl     0:14 RoonBridgeHelper --debug --gc=sgen --server RoonBridgeHelper.exe
   22 ?        S      0:00 /boot/bin/RoonBridge/Bridge/processreaper 18
   26 ?        Sl     0:10 RAATServer --debug --gc=sgen --server RAATServer.exe
   71 pts/0    Ss     0:00 /bin/bash

[rubin55]

I've looked at the Logs directories onder /data, I notice that RAATServer's logs indicate that no audio devices are found:

11/28 07:56:14 Trace: [raatmanager] starting server
11/28 07:56:14 Info: [jsonserver] listening on port 42333
11/28 07:56:14 Trace: [raatmanager] announcing
11/28 07:56:14 Trace: [jsonserver] [192.168.1.101:50215] accepted connection
11/28 07:56:14 Debug: [discovery] broadcast op is complete
11/28 07:56:14 Trace: [jsonserver] [192.168.1.101:50215] GOT[LL] [1] {"request":"enumerate_devices","subscription_id":"0"}
11/28 07:56:14 Trace: [jsonserver] [192.168.1.101:50215] SENT [1] [nonfinal] {"status": "Success", "devices": []}

192.168.1.101 is my mac-mini with the Roon software. I have another raspberry that shows that devices array with an entry that looks like an alsa card stanza. I installed alsa tools within the container to verify that I can see the alsa card, and I can, however, it does not seem to show up as far as RAATServer is concerned.

[rubin55]

I've tested playing to the alsa device from within the container, using aplay:

root@allo:/# aplay /tmp/sample2.wav 
Playing WAVE '/tmp/sample2.wav' : Signed 24 bit Little Endian in 3bytes, Rate 96000 Hz, Mono

This worked as expected.

[dubo-dubon-duponey]

Hey @rubin55

Sorry for your issue.

The messages you saw in the logs, and the process list are expected.

On my side, here is what I get in the logs:

11/28 14:08:42 Trace: [jsonserver] [10.0.4.49:41586] GOT[LL] [1] {"request":"enumerate_devices","subscription_id":"0"}
11/28 14:08:42 Trace: [jsonserver] [10.0.4.49:41586] SENT [1] [nonfinal] {"status": "Success", "devices": [{"type": "alsa", "device_id": "hw:CARD=sndrpihifiberry,DEV=0", "name": "snd_rpi_hifiberry_digi", "config": {"unique_id": "d6b4258e-8932-5be3-5cf3-311933ba103f", "external

The differences between your setup and mine are:

• I do not use the pi onboard sound chip (I'm using dedicated hifiberry DAC tops)
• my host is debian, your host is alpine

So, can you copy a couple of things?:

• cat /boot/config.txt
• get inside the container (docker exec -ti raat bash) and run ./boot/bin/RoonBridge/check.sh

Also, I did not understand this sentence: "I have another raspberry that shows that devices array with an entry that looks like an alsa card stanza"

So, ^ are you saying that you have another RPI where running the container show the alsa device, and the roon bridge is working?

[dubo-dubon-duponey]

Also, what kernel are you running on the host?

[dubo-dubon-duponey]

I installed alsa tools within the container to verify that I can see the alsa card, and I can, however, it does not seem to show up as far as RAATServer is concerned.

Can you also try running the container with --user=root?

[rubin55]

Hi @dubo-dubon-duponey, I'm currently not at the console of the system (setting this up for a friend + now back home), but let me answer your questions to the best of my abilities:

• In this case also not using the embedded RPI audio, but an external usb attached DAC (T+M whatchamacallit USB Audio - verified working with aplay as commented on before)
• I've run ./boot/bin/RoonBridge/check.sh which outputs that everything is green + good to go (within the container of course)
• Kernel version is 5.4.x, the stock alpine rpi kernel
• About the other RPI: no, that was another RPI with Ropieee; I later also tested the Ropieee image with this hardware just to be sure that everything works cabling/hardware wise; incidentally, my config.txt (don't have it right now) is identical to the config.txt of Ropieee

Good point about running with --user=root; will definitely try that tomorrow when I drop by there to pick up my forgotten power adapter :-)

[dubo-dubon-duponey]

Ok, thanks. Rules out kernel.

I'm thinking one of:

1. permission issue: I suggest you try prove/disprove this by running the container without any of the tightening (remove capdrop, force root user, run with privileged)

docker run --privileged --net host --name bridge --user root --rm dubodubonduponey/roon-bridge

2. there is another system on the host that acquired a lock on alsa (eg: librespot, airport, ...) <- Roon will fail in that case IIRC

Can you look at what's running there that may talk audio? (containerized or host)

Let me know your findings.

[rubin55]

Hey! That was it! --user root makes RoonBridge work. Note also that I don't have to specify --privileged and I can keep --read-only --cap-drop ALL and the --device /dev/snd specification. I suspect the user, even though there is the --group-add option for the audio group, is not allowed to do "something" with the alsa interfaces.

[dubo-dubon-duponey]

Ok, that's... reassuring I guess :-).

I'm not using Alpine on the host, so, I will not be able to look into this further for now.

If you figure out "what" exactly Alpine is expecting to be able to access the device, let me know so that I can document.

Glad the "--user root" hack solved it for you though! As you are running read-only with cap-drop (and no --privileged) you should still have something pretty tight in that scenario.

Cheers.

[Martynet]

Hi, I have Synology NAS, running Roon server. And it's working great. I can access it from all my devices, no issues. I bought a new DAC for living room and before I spend money for music streamer device or raspberry pie, I decided to try installing "Roon bridge" in Mecool KIII Pro box, running CoreElec OS. I installed Docker, then Portainer, Watchover and finally Roon Bridge. So, Roon Bridge container is up and running, but It's not visible to Roon server for some reason. This is the command I used deploying it: docker run --name RoonBridge --net=host -e TZ=Europe/Dublin -d -v /storage/.config/docker/roon:/var/roon dubodubonduponey/roon-bridge:latest

After reading the above, I tried to deploy the image with modified command: docker run --name RoonBridge --user root --net=host -e TZ=Europe/Dublin -d -v /storage/.config/docker/roon:/var/roon dubodubonduponey/roon-bridge:latest

Adding "--user root", but that didn't help. I still have same stuff in logs and Roon bridge is not visible to the Roon server. Here's the log:

00:00:00.015 Warn: get lock file path: /tmp/.rnbgem0- 00:00:00.369 Trace: [childprocess] using unix child process Initializing 00:00:00.558 Info: Starting /boot/bin/RoonBridge/Bridge/RoonBridgeHelper 00:00:00.588 Info: ConnectOrStartAndWaitForExit RAATServer, path: /boot/bin/RoonBridge/Bridge/RAATServer Not Running (.o) 00:00:00.034 Warn: get lock file path: /tmp/.rnbhgem0- Running

Thank you for any help with this

[dubo-dubon-duponey]

@Martynet I'm unfamiliar with CoreElec.

Why would you think the above comment would apply though? This discussion was about Alpine Linux. Either way, will answer you on the other ticket then, since your problem is likely different.