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.