Roon Ready is the certification tier that puts Roon Advanced Audio Transport, or RAAT, inside a manufacturer's own firmware. It is distinct from Roon Tested, which covers devices Roon has verified but which speak to Roon through some other path such as USB or AirPlay. Roon Labs has been a standalone Harman business unit since the acquisition was announced on 27 November 2023, and Harman put the ecosystem at more than 160 audio brands and over 1,000 devices at the time. That scale is the reason the certification bar is where it is.

Manufacturers tend to budget Roon Ready as a two-week firmware task. On an embedded Linux streamer with a USB Audio Class 2 output stage and more than one streaming service on board, it is a multi-month systems project. The published requirements explain why.

The published bar

Roon Labs publishes its RAAT SDK certification requirements as an open PDF, and it is worth reading before quoting a schedule. The document is specific. A certified device reports vendor name, model name, serial number, hardware and firmware version, and RAAT SDK version. It supports two-way synchronized volume control, and volume must remain readable and controllable from Roon while the device is streaming from a different service, sitting on a non-networked input, or in network-aware standby. It reports on-device DSP in the Roon Signal Path in real time, including the correct output method, so USB reads as USB rather than a generic ALSA sink. It sustains 24 hours of continuous playback and switches formats without audible artefacts. It survives a power-cycled switch, a pulled Ethernet cable at either end, and interfaces coming up and down. Devices that pass audio through to a USB port hand Roon the USB IDs and manufacturer strings of whatever is attached. And the implementation source is submitted to Roon for review.

Two clauses drive most of the engineering. The first is format parity: whatever the product advertises, and whatever it can already play over UPnP or a built-in service app, it must also play over RAAT. The second is convenience switching. Starting playback in Roon has to switch the input and start the stream, and the requirements explicitly count Spotify Connect and AirPlay as inputs for that purpose. The device must stay discoverable in Roon the whole time it is powered and on the network.

DoP or native DSD is a silicon question

DSD over PCM is the fallback path, standardized in the DoP open standard. A 24-bit PCM frame carries 16 bits of DSD payload in its lower bits, and the upper eight bits carry a marker that alternates between 0x05 and 0xFA on every frame. A receiver must see 32 consecutive valid marker bytes on every channel in use before it switches into DSD mode, and a single missing marker sends it back to PCM. The design intent is that a decoder that never notices the markers produces low-level noise rather than full-scale digital hash.

The cost is bandwidth. DoP needs a PCM carrier at 1.5 times the equivalent PCM rate of the DSD stream. DSD64 at 2.8224 MHz rides on a 176.4 kHz carrier. DSD128 at 5.6448 MHz needs 352.8 kHz. DSD256 at 11.2896 MHz needs 705.6 kHz, and DSD512 at 22.5792 MHz needs 1411.2 kHz. Very few UAC2 endpoints declare a PCM alternate setting that high, which is why anything above DSD128 is a native DSD conversation in practice.

Native DSD on Linux means the SNDRV_PCM_FORMAT_DSD_U8, DSD_U16 and DSD_U32 formats, in both endiannesses. The big-endian variants were added to ALSA by Jussi Laako and merged by Takashi Iwai specifically because several XMOS-based interfaces expect that byte order. Getting them out of a USB device requires alsa-lib 1.0.29 or newer and, on most parts, a quirk in snd-usb-audio that selects a vendor-specific alternate setting rather than a standard UAC2 one. The driver now does generic detection for XMOS-based UAC2 devices under vendor ID 0x20b1 instead of listing each product.

The practical lesson is that the USB receiver silicon decides, and the datasheet is not always the arbiter. Parts in this class, meaning XMOS xcore.ai and xCORE-200 designs, Comtrue CT7601, Savitech and similar bridges, frequently ship firmware images with narrower DSD support than the marketing sheet claims, and the same document will state DSD512 in one table and DSD256 in another. Read /proc/asound/card*/stream0 and run alsacap against the actual board with the actual loaded firmware. On one integration we scoped to DSD512, found no native DSD formats exposed at all on the first firmware image, and settled the ceiling only after the bridge firmware was rebuilt. Advertise what the hardware enumerates. The certification requirements make a mismatch a failure rather than a rounding error.

One PCM device, six services

This is the part nobody schedules for. An ALSA hw:X,0 device is single-open. A product that carries RAAT plus Spotify Connect, Tidal Connect, Qobuz Connect, AirPlay and UPnP has six processes that each believe they own the output, and a software mixer is not an option because bit-exact delivery is the entire premise.

Convenience switching turns this into a hard requirement. Roon must be able to start playback at any moment, from any prior state, and the RAAT process must remain discoverable and volume-responsive the whole time it is not playing. That rules out the obvious approach of stopping and starting service processes. The RAAT integration has to release the PCM device and stay resident.

A workable arbitration layer looks like this. A single shared state word, held in System V shared memory and visible to every service, names the current audio owner. Before any service opens the PCM it declares intent, the incumbent tears down its output and keeps its network presence alive, and only then does the new owner open the device. Services that expose no snd_pcm symbols, because their audio goes through a vendor library rather than libasound directly, cannot be intercepted with an LD_PRELOAD shim and need a different hook. Services with persistent client sessions will reconnect within a second of losing the device and start a reclaim loop against each other, so the arbiter needs a hysteresis window on the order of 12 to 15 seconds per source.

Two smaller items belong in the same pass. On-SoC HDMI and I2S codecs enumerate as ALSA cards and will otherwise appear in Roon as endpoints the customer can select and get silence from. And multi-zone grouping needs per-rate output-delay compensation, because fixed pipeline latency in a USB bridge does not scale linearly with sample rate, so a single offset tuned at 44.1 kHz will not hold at 352.8 kHz.

Deployment and version discipline

Containerising the services buys clean per-service dependency isolation on an ARM64 SoC. It also costs. Every container needs ipc:host to see the shared arbitration segment, mDNS registration should go through one avahi-daemon on the host over a mounted D-Bus socket rather than several instances fighting for UDP 5353, and a RAAT binary cross-compiled against glibc needs its interpreter and RPATH patched before it will run in a musl-based runtime. Budget for it.

Finally, certification attaches to a build. The device reports its RAAT SDK version to Roon, and field units running an older firmware are, for support purposes, a different product. Decide early whether the certified build is the one already on production units or a replacement, and get the fleet onto one version before the certification listing goes public. A listing that appears before the firmware ships generates support tickets from owners who cannot find the feature.

References