RoonReady vs RoonBridge on Linux

I am trying to understand what is the difference between RoonReady vs RoonBridge on Linux platforms ? The Sonore guys seems to suggest the RoonBridge has dependencies on .NET framework and its a crud to work on Linux. What I understand from the below post is RoonReady can be compiled natively (from C code) whereas RoonBridge and its associated dependencies is possibly a port from Windows ?

I am using a low powered Celeron NUC as a streamer running RoonBridge under AudioLinux. If there is a benefit of RoonReady is terms of sound quality, is it possible to get a compiled version of RoonReady for the NUC as well ?

Thanks in advance.

1 Like

RoonReady is a status applied to consumer devices that are running Roon SDK and fully support RAAT and part of the partner programme, it’s not something you can install. Roonbridge is the equivalent as software solution to enable computers and SBC to be Roon endpoints. There is nothing crud to make it work on Linux it works really well and no there is no difference in sq.

I understand the status quo for RoonReady. What I meant is the s/w that runs in RoonReady devices. Are you suggesting that a RoonReady device runs RoonBridge s/w underneath ?

No not at all. But they are achieving the same goal from different angles.

If the s/w is different on RoonReady devices, it would be worth to see if the same s/w can make SQ differences on a standard NUC.

@brian is best to comment on the differencez if any between the SDK code and Roonbridge.

The RoonBridge is based on .net like Roon server. Roon Ready code is run on embedded players and network DAC. It is written in C. The Roon Ready code is much more flexible and lightweight then RoonBridge and it can be tailored to the device it runs on.

Think of the RAAT SDK as a building block for making stuff that speaks the RAAT protocol.

We used the RAAT SDK to build Roon Bridge, and partners use the RAAT SDK to build audio products. We also used the RAAT SDK to build our iOS/Android implementations inside of Roon Remote, and the same for Windows/Mac Roon apps.

The underlying code that speaks RAAT is the same in all cases. The benefit of Roon Ready products is:

  • The end-to-end experience is reviewed, iterated on, and certified here at Roon Labs
  • Partners are required to implement certain features like convenience switching, standby controls, volume controls from Roon, etc as part of the certification process. The RAAT SDK has all of the right extension points to make this possible.
  • Roon Ready products are generally more optimized for audio use cases than computers.

The most important benefit is the first one–we go out of our way to ensure a consistent/reliable experience with Roon Ready products. Aside from that, if you are comparing to a “simple” Roon Ready product that is doing nothing more than bridging to a USB DAC, the primary benefit is the last one–optimized hardware. Offering the SDK to manufacturers gives them more power to integrate product features, in return for the obligation to get that integration certified before releasing it.

As for the concerns about .NET…the RAAT endpoint running inside of Roon Bridge is not running in .NET–it is the same C code used on Roon Ready devices. Actually, we are very careful to prevent the .NET runtime from ever binding to any threads related to RAAT because otherwise the .NET garbage collector can pause those threads and cause audio performance issues.

The .NET code is used only for creature comforts–to integrate with the taskbar on windows/menubar on mac, and to manage the software update mechanism. Doing it in .NET lets us share more code with the main Roon app, instead of having one-off copies for Roon Bridge that eventually fall out of sync. We take care to isolate the C-based RAAT stuff, which is written pretty minimally with an embedded-systems-programming mindset, from the .NET runtime.

There is no “porting from windows” aspect here. The same C code for RAAT runs on Windows, Mac, Linux, iOS, Android and (to my knowledge) is in production use on x86, x64, armv7a, armv8, mips, and powerpc. It’s very portable stuff, all in a single codebase, and mostly based on posix and libuv, which though compatible with Windows, primarily target posix platforms.

Roon has been a cross platform project from the beginning…it did not start out as a Windows app. Actually, most of the code was written by people sitting in front of Mac or Linux machines, typing into vim and emacs, and building the code with GNU Make. We use .NET as a cross-platform runtime because it is good for that, but don’t function like a typical .NET team.

In summary–if you are just bridging between the network + a standard audio driver mechanism like CoreAudio, ALSA, WASAPI, ASIO, etc, the exact same code is running on Roon Bridge + a Roon Ready endpoint doing the same thing. The benefits of the Roon Ready endpoint are not access to better or more optimized code–Roon Ready is about achieving a tighter integration with non-audio-related product features, integrating directly into hardware that is optimized for audio playback, and most importantly a certification process that ensures quality implementations.


Thanks Brian for a clear explanation.

yes, thanks Brian for the explanation. Appreciate it.