Hi! What’s not quite right with Roon?
· None of the above quite fits
None of the above quite fits
· None of these quite match
Tell us what's going on
· RoonBridge 2.71 build 1683 / .NET 10 – reproducible RAATServer startup/lifecycle issue on ARMv7 (Raspberry Pi 2 / Volumio 4)
Tell us about your home network
· Hello Roon Support,
I would like to report a reproducible RoonBridge startup/lifecycle problem affecting RoonBridge 2.71 build 1683 on a Raspberry Pi 2 Model B running Volumio 4.
I have investigated this in some depth and have a reproducible A/B test and a working systemd workaround.
This does not appear to be the libicu/glibc installation problem that has also been reported for build 1683 on ARMv7.
SYSTEM
Hardware:
Raspberry Pi 2 Model B rev 1.1
Revision code: a01041
CPU: ARMv7 / Cortex-A7, four cores
Architecture: armv7l
OS:
Volumio 4.119
Debian Bookworm based
Kernel: Linux 6.12.74-v7+ armv7l
Runtime:
glibc 2.36
OpenSSL 3.0.19
libicu72 installed
Roon:
RoonBridge 2.71 build 1683
Production
linuxarmv7hf
.NET 10 generation
Audio device:
OPPO USB Audio Device connected directly by USB
Roon Server is on another machine on the same LAN.
ROON COMPATIBILITY CHECKS
Roon's supplied check.sh returns:
Checking for a supported glibc version [ OK ]
Checking for Binary Compatibility [ OK ]
Checking for libstdc++ [ OK ]
Checking for libicu [ OK ]
Checking for ALSA Libraries [ OK ]
STATUS: SUCCESS
I also checked the RAATServer executable using ldd. All required libraries resolve successfully; there are no "not found" dependencies.
ALSA is working correctly.
aplay -l reports:
card 5: Device [OPPO USB Audio Device], device 0: USB Audio [USB Audio]
The corresponding ALSA playback device is available as:
hw:CARD=Device,DEV=0
/dev/snd contains the expected control and playback devices.
I also checked device contention. No other process was holding the OPPO PCM playback device.
There were no relevant kernel messages indicating:
- segmentation faults
- illegal instructions
- OOM kills
- RAATServer crashes
- USB audio failures
FAILURE WITH NORMAL ROONBRIDGE STARTUP
With the normal RoonBridge startup path, the Roon endpoint does not initially appear.
RoonBridge repeatedly logs:
ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
followed by:
ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one
and then approximately several seconds later:
System.Net.Sockets.SocketException (111): Connection refused [::ffff:127.0.0.1]:9004
followed by:
Not Running (.o)
The process then retries.
Without intervention this previously resulted in an ongoing RAATServer startup/retry cycle and the endpoint was unavailable in Roon.
RAATSERVER ITSELF WORKS
I then stopped RoonBridge and launched the RAATServer executable directly, using the same Roon data environment:
ROON_DATAROOT=/data/configuration/music_service/RoonBridge
ROON_ID_DIR=/data/configuration/music_service/RoonBridge
Executable:
/data/plugins/music_service/RoonBridge/RoonBridge/Bridge/RAATServer
This starts successfully.
The RAAT log shows:
Starting RAATServer v2.71 (build 1683) production on linuxarmv7hf
detected ALSA support
and correctly finds the USB DAC:
FOUND id=hw:CARD=Device,DEV=0
vendor=OPPO
name=OPPO USB Audio Device
It then successfully:
- initializes the RAAT manager
- starts network discovery
- opens the local/control server
- listens on TCP 9200
- establishes the local RAAT control path
- accepts a connection from the Roon Server
- responds successfully to enumerate_devices
- exposes the OPPO USB Audio Device
The direct/manual startup takes approximately seven seconds on this Raspberry Pi 2 before RAAT reaches its manager/server-ready state.
A/B TEST
The most useful test was the following.
1. Stop RoonBridge.
2. Start RAATServer manually.
3. Wait until TCP 127.0.0.1:9004 is listening.
4. Start RoonBridge.
With RAATServer already ready, RoonBridge logs:
ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
but does NOT immediately enter the previous failed-launch cycle.
The Raspberry Pi then appears correctly in:
Roon > Settings > Audio
The OPPO USB Audio Device appears as a native ALSA device, can be enabled, and plays audio correctly via RAAT.
This proves that:
- the ARMv7 RAATServer binary works on this Pi
- the current RoonBridge/RAAT binaries can run on this system
- ALSA works
- the OPPO USB interface works
- LAN discovery and communication with Roon Server work
- actual audio playback through Roon -> RAAT -> ALSA -> OPPO works
The failure therefore appears to be associated with startup/lifecycle coordination rather than basic binary compatibility.
SYSTEMD WORKAROUND
I created a separate RAATServer service:
/etc/systemd/system/roon-raat-prestart.service
Contents:
[Unit]
Description=Pre-start Roon RAATServer
[Service]
Type=simple
Environment=ROON_DATAROOT=/data/configuration/music_service/RoonBridge
Environment=ROON_ID_DIR=/data/configuration/music_service/RoonBridge
WorkingDirectory=/data/plugins/music_service/RoonBridge/RoonBridge/Bridge
ExecStart=/data/plugins/music_service/RoonBridge/RoonBridge/Bridge/RAATServer
Restart=always
RestartSec=1
I then added a systemd drop-in for RoonBridge:
/etc/systemd/system/roonbridge.service.d/raat-prestart.conf
Contents:
[Unit]
Wants=roon-raat-prestart.service
After=roon-raat-prestart.service
[Service]
ExecStartPre=/bin/systemctl restart roon-raat-prestart.service
ExecStartPre=/bin/sh -c 'for i in $(seq 1 120); do ss -ltn | grep -q "127.0.0.1:9004" && exit 0; sleep 0.25; done; echo "RAATServer did not become ready on port 9004"; exit 1'
The second ExecStartPre is deliberately state-based rather than a fixed delay: RoonBridge is released as soon as port 9004 becomes available, with 30 seconds merely acting as a maximum safety timeout.
COLD-BOOT RESULT
This workaround has now survived a complete Raspberry Pi reboot without any manual intervention.
After boot:
- RoonBridge is active
- RAATServer is active
- 127.0.0.1:9004 is listening
- 0.0.0.0:9200 is listening
- the Raspberry Pi endpoint appears automatically in Roon
- the OPPO endpoint appears
- audio playback works normally
However, the cold-boot journal is particularly interesting.
It still recorded:
ConnectOrStartAndWaitForExit RAATServer: Try to connect to existing raatserver
then:
ConnectOrStartAndWaitForExit RAATServer: Failed to connect to existing raatserver, let's start one
and:
System.Net.Sockets.SocketException (111): Connection refused [::ffff:127.0.0.1]:9004
before subsequently retrying and recovering.
The separate RAAT service reported:
NRestarts=1
After that single automatic restart, RAATServer remained continuously alive and stable.
Several minutes after boot the processes were still running normally, including the same RAATServer PID, and playback remained stable.
INTERPRETATION
My current interpretation is therefore not that ARMv7 is fundamentally incompatible with RoonBridge 2.71.
The hardware successfully runs the software and plays audio once the RoonBridge/RAATServer relationship becomes established.
Rather, the evidence points to a startup/lifecycle race or timeout assumption between RoonBridge and RAATServer that becomes visible on relatively slow ARMv7 hardware.
The migration of RoonBridge 2.71 build 1683 to .NET 10 is obviously correlated with when this problem appeared, but I cannot establish from the outside whether .NET 10 itself is the root cause.
The important observation is that RoonBridge's ConnectOrStartAndWaitForExit() logic appears not to tolerate the actual RAATServer startup/lifecycle timings on this hardware.
The independent systemd supervision converts what was previously an indefinite startup failure into:
cold boot
-> initial RAAT/RoonBridge synchronization failure
-> one RAATServer restart
-> successful connection
-> stable operation and playback
REQUEST
Could you please investigate:
1. the startup timeout/retry behaviour in ConnectOrStartAndWaitForExit();
2. RAATServer's approximately 20-second clean exit behaviour when the expected relationship with RoonBridge is not established;
3. whether the .NET 10 migration has increased startup latency sufficiently to expose an existing timing assumption on slower ARMv7 devices;
4. whether RoonBridge should wait for an explicit RAATServer-ready state rather than relying on a short fixed timing window;
5. whether ARMv7/Raspberry Pi 2 class hardware is still intended to be supported by build 1683.
I would be happy to provide the complete RoonBridge and RAATServer logs, additional systemd journals, or reproduce the behaviour with the workaround removed if this would help engineering.
I am also reporting the integration aspect to Volumio, since their RoonBridge plugin provides the systemd launch environment, but the failing 127.0.0.1:9004 handshake and ConnectOrStartAndWaitForExit() behaviour appear to be inside RoonBridge itself.
Thank you.