Jason has a Schiit Jotunheim on his desk โ€” a balanced headphone amp with a swappable Multibit DAC card โ€” connected via USB to his Linux desktop. Roon Core runs on a TrueNAS VM at 172.16.0.98. The goal: make the Jotunheim a Roon audio zone while keeping it available for PipeWire (video calls, system audio).

It took six distinct problem layers to get there. Here they are.

Schiit Jotunheim 3

The Jotunheim’s Quirks Link to heading

The Jotunheim has a physical analog volume knob โ€” it exposes no ALSA mixer element. Roon’s default volume.type: "alsa" fails silently (“device not found”). The fix is "software" volume โ€” Roon attenuates digitally before handing off.

It also identifies over USB as Schiit USB Multibit (the DAC card’s name), not “Jotunheim.” That’s fine once you know it.

Six Things That Broke Link to heading

1. Roon Bridge not appearing in Core UFW was blocking TCP 9200 (RAATServer). Fixed:

sudo ufw allow from 172.16.0.0/20 to any port 9200 proto tcp

2. “Device not found” โ€” wrong service user Roon Bridge runs as root by default. PipeWire runs as the logged-in user. Root can’t reach the user’s PipeWire session. Fix โ€” /etc/systemd/system/roonbridge.service.d/override.conf:

[Service]
User=jason
Environment=XDG_RUNTIME_DIR=/run/user/1000
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

Also: sudo chown -R jason:jason /var/roon

3. “Device not found” โ€” wrong volume type In /var/roon/RAATServer/Settings/device_<id>.json, change "type": "alsa" to "type": "software".

4. ALSA device: plug:pipewire, not default RAATServer probes devices with snd_pcm_hw_params_any(). PipeWire’s default device doesn’t respond to this correctly. plug:pipewire wraps PipeWire in ALSA’s plug layer, which handles the probe. It also routes through PipeWire’s mixer, so Roon and system audio coexist.

In the same device JSON: "device": "plug:pipewire".

5. Stuck on “enabling…” โ€” TCP firewall RAAT allocates a dynamic per-device TCP port (30000โ€“65535) after the initial 9200 handshake. UFW was blocking it:

sudo ufw allow from 172.16.0.0/20 to any port 30000:65535 proto tcp

6. Songs scrolling every ~2 seconds โ€” UDP clock sync This is the one nobody documents. RAAT uses a UDP port in the 30000โ€“65535 range for clock synchronization. TCP audio was flowing fine; UDP clock sync was blocked. Roon times out the stream after ~1 second and skips to the next track. The RAATServer log would send {"clock_port":59430,"audio_port_tcp":33035,"status":"Success"} and then go silent.

sudo ufw allow from 172.16.0.0/20 to any port 30000:65535 proto udp

This was the fix that made everything work.

Complete Config Link to heading

UFW rules (all three required):

sudo ufw allow from 172.16.0.0/20 to any port 9200 proto tcp
sudo ufw allow from 172.16.0.0/20 to any port 30000:65535 proto tcp
sudo ufw allow from 172.16.0.0/20 to any port 30000:65535 proto udp

Device JSON (/var/roon/RAATServer/Settings/device_<id>.json):

{
  "volume": {"type": "software"},
  "output": {"type": "alsa", "device": "plug:pipewire", "name": "Schiit USB Multibit"},
  "external_config": {}
}

Stop Roon Bridge before editing, restart after.

Port Reference Link to heading

PortProtocolPurpose
9003UDPSOOD discovery
9200TCPRAATServer control
30000โ€“65535TCPRAAT device + audio
30000โ€“65535UDPClock sync โ† the one everyone misses