Is a music-management application that costs $499 USD expensive? That’s what you’ll pay for a lifetime subscription to Roon, and I’ve occasionally called it “an expensive option.” If you don’t want to plunk down half a thou, you can pay $119 for a one-year subscription.
Rob Darling, director of strategy for Roon Labs, is having none of that “expensive” talk. “People like to say Roon is expensive, but it’s expensive only compared to other apps,” he says. “As a component of your hi-fi system, Roon is not expensive. iTunes is free, but you paid a lot for your Mac, and that cost is hidden there. Compared to other pieces of your hi-fi system -- the DAC, speakers, amp, headphones -- Roon isn’t truly expensive.”
Roon’s roots go back two decades, when a group of music-lovers, one of them Darling, developed a software platform with a rich touch interface, for managing big libraries of digital music files. Next they developed a hardware platform that could run that software, complete with touchscreens that would let users browse their libraries from the couch. That ultimately became the Sooloos network music system, which was launched in 2006, then sold to Meridian Audio in 2008. In 2015, the Sooloos team left Meridian and formed Roon.
The Sooloos system cost $12,900. By comparison, Roon is downright cheap -- even when you factor in the cost of the hardware you need to run Roon. Roon is more expensive than many other very capable music apps, but it delivers a far richer experience, with one-tap access to album reviews, artist bios, song lyrics, liner notes -- even instruction manuals for playback devices.
The subscription fee buys you a license to install the Roon Core software on a single PC, Mac, or Linux computer, or on a dedicated Roon server. Roon Core manages your music library, and controls playback of music through Roon-capable devices on your home network. You control playback using the Roon Bridge app on a PC or Mac, or the Roon Remote app on an iOS or Android device. Those apps are free.
I’ve installed Roon Core on a modified, mid-2011 Mac Mini in my second-floor home office. Connected to the Mini’s USB port is an iFi iDSD Micro BL DAC-headphone amp, which I use with HiFiMan Edition X V2 planar-magnetic headphones. iFi is one of 48 manufacturers that offer Roon Tested DACs. Downstairs in the living room, I have a Bluesound Node 2i streaming preamp whose S/PDIF coaxial output is connected to the digital input of my Dynaudio Focus 200 XD active speakers. Bluesound is one of 65 brands offering Roon Ready network music players. In this interview, Darling explains how the Roon Ready and Roon Tested programs work.
The iFi and Bluesound components are my main sources for daily listening. In addition, over the past year I’ve used Roon in reviews of products from Bowers & Wilkins, KEF, Kii Audio, Naim Audio, Primare, and Pro-Ject.
No software platform is 100% bulletproof, but Roon comes close -- impressive when you consider the wide range of products it supports. I wanted to talk to Roon Labs about the certification process that enables this. I also discussed the processes Roon goes through to get its apps approved for iOS and Android, and what’s involved in integrating into Roon such streaming services as Tidal and Qobuz.
Gordon Brockhouse: A lot has been written about Roon’s rich editorial content, polished interface, excellent sound quality, and extensive DSP features. What’s less noticed is Roon’s ability to work with so many products from so many different manufacturers. How does this happen?
Rob Darling: Roon moves audio around on a software protocol we call RAAT -- Roon Advanced Audio Transport. When you use Roon inside a single computer, audio moves around on RAAT, and Roon uses RAAT to move audio around on connected and networked devices.
RAAT has two components. It’s a discovery engine -- a little application running inside a device that says, “Hey, I’m a Roon thingie that plays audio.” And it’s a set of plumbing connections that enable Roon to play music locally, or over a network. When you install the Roon Remote app on an iOS or Android device, the RAAT code exposes the audio outputs of that device to the Roon Core, so you can stream to it. When you install the Roon Bridge app on a Mac, PC, or Linux box, the RAAT code exposes all audio output devices connected to that computer to the Roon Core.
When a manufacturer makes a Roon Ready device, what they’re doing is making a customized version of the RAAT app for that device. They’re making an app that says, “Here I am. Is there a Roon Core that wants to talk to me?” A Roon Core on the same network says, “Sure,” and now that device can start working with Roon.
There are many ways our hardware partners can customize RAAT. Playing audio is fine, but it’s not enough. If I own a cool piece of hardware, I want to be able to take advantage of its capabilities. I want to be able to use its remote to change volume, and move the track forward or back. If there’s a snazzy screen on the front of my device, I want to see Now Playing information. If I’ve been on the USB input, or my kids have been using AirPlay, when I start Roon I just want to press Play and hear music. I don’t want to have to find the remote control and switch inputs. We call that capability “convenience switching.” If I’ve been on the USB input, and the display on the front panel of the device says the volume is set at -40dB, I don’t want Roon’s volume display to say something different, because then I’m going to be confused.
The first customization a manufacturer makes is declaring the device’s audio capabilities. RAAT code running in the device tells Roon Core, “I’m a Bryston BDP-3, and I can play PCM audio up to 32-bit/384kHz and DSD up to DSD128.”
Then you declare if the device has a volume control, the range of the volume control, and how many steps it has -- say, a range from -100 to 0dB, with 200 steps. We require that users be able to control volume of any device connected to Roon from the Roon app. If the device doesn’t have its own volume control, there’s a digital volume control in the SDK [software development kit] that the manufacturer can enable on their device.
The last chunk of information reported is the device’s DSP capabilities and states. Does the device have EQ? If so, what forms of EQ? Is it on or off? What are the settings? Does it do resampling? Is resampling on or off, and what is happening to the stream Roon is sending? Does the device support MQA? If it supports MQA, is it an MQA renderer or decoder?
We require that manufacturers report all this stuff, so we can show it in Roon’s Signal Path. If a customer tells us, “My device sounds really weird with Roon,” we ask them to hit the Signal Path button at the bottom of the Roon screen. Then they might see that another user had been playing with the device’s EQ, and that’s why it sounded weird. And if a hardware partner has really cool DSP capabilities, they can show it off in Signal Path.
Also, we found early on that companies sometimes do things to the audio that they don’t tell customers about. A company might say their device supports 768kHz PCM. Sure, you can stream 768kHz PCM to it, but everything gets downsampled when it comes off the network card. We’ve had to have some uncomfortable conversations with partners about things like that.
We do this because we don’t want to see a situation where customers would say, “Roon doesn’t sound as good over the network as the USB input when I’m playing hi-rez audio.” And maybe they are right, because, for some pipeline reason, there isn’t enough bandwidth between the network card and the DAC, so the device is accepting hi-rez input from Roon Core, then downsampling it, and it truly sounds different -- and maybe worse -- as a result. We wanted to be in a position to let customers know what’s going on under the hood.
Those customizations are the hard work our hardware partners do to make their products Roon Ready. Often, they’ve never faced these requirements before. We ask them to do all of this, because we want our customer to feel like their device is an extension of Roon, and Roon is an extension of their device -- rather than products from two different companies.
GB: When a hardware company wants its components to be Roon Ready, what’s the first step?
RD: The first step is signing a license agreement that says they agree to the terms of how our software will be used in their device, and that it will meet our requirements. Then they share a bunch of contact information with us. Once they’ve done that, everyone in their company gets free licenses to use Roon. Then they download the SDK and start working. Hopefully, they’ll ask us questions. Along the way, they run a bunch of QA [quality assurance] tests to make sure their stuff will pass certification.
When they’ve finished the customization needed to implement Roon, they send us a device and we start testing. We send them feedback, specifying the areas where their device falls short of our certification requirements. These may be sloppy little things like not giving the right name of the device. Or they’ll name audio outputs incorrectly. Or the volume control in the software won’t have the right number of steps. There may be things they hoped wouldn’t apply to them when they read the certification requirements, or functions they haven’t implemented properly, like convenience switching.
Then you’ll get devices that are real Swiss Army knives. They might have a headphone output, digital output, and analog output, with separate volume states for each. The volume might even be handled by different processes in the device. They’re just very complex, so they often have a lot of issues that take a lot of repeat testing.
The partner will rarely be as diligent as we are about testing, which we understand, since Roon capability is one of 150 features on their device. But to us and to Roon users, it’s critical that everything be right. That’s the most important aspect of the Roon Ready program. Apart from our technology being robust, we enable a very high-level user experience. And then we test it, so when that product goes out the door, we know it’s going to work.
GB: Is it common for a product to get through on one pass?
RD: No one has ever made it through on a single pass. We had one product that received only one point of feedback, and that was a situation where they actually asked us a question about the issue but misunderstood the answer. Otherwise, they would have passed on the first round.
Other partners will occasionally have only four or five points of feedback over a couple of tries. But it’s more common that it takes five or six tries. Sometimes people haven’t been paying attention, or didn’t do a very good job at QA. Then we have to ride them really hard, and there is a lot of back-and-forth.
GB: Do you keep the products on hand after you’ve certified them? If you issue a software update, how do you ensure compatibility of the new version with products that have already been certified?
RD: Generally, we don’t make a lot of changes to RAAT itself, or to the Roon Ready SDK. When we make changes, they’re usually for a specific device, to help it integrate with the rest of the family. A device comes along with a new DSP, and we have to make additions to the SDK to enable that. Most of the RAAT plumbing happens at the Roon side, not on the device, so we can make changes, and it’s not really a problem for all devices always to be current.
When we make changes, it’s a huge value to have all the devices on hand. For example, we made a major change last winter about how sync is initiated, in order to make it easier for devices that had older architectures to sync at high sampling rates. These devices weren’t fast enough, and they were struggling. When we make a change like that, we roll it out very softly. We start with our alpha testing community of a couple of hundred people who have a wide range of devices. We plug in the devices and test them thoroughly to make sure everything is going to work. This is why we hold on to all the devices, so we can make updates, and know that everything will work.
The other reason we hold on to devices is so customers don’t get bounced back and forth between us and the manufacturer if they have a problem. If you’re having a problem, we can quickly step in and say, “We have the device, and we’ve identified this problem. You just need to hit this button, or you’re just confused about this.” Or maybe the customer has revealed a new edge case about this device, and we can collaborate with the manufacturer and solve the issue.
GB: Looking at this from the other side: If the manufacturer issues a firmware update or a Mk.II version, how can you ensure that Roon will continue to operate correctly?
RD: This can be problematic. There are a couple of manufacturers who do regular updates. We hope they are testing well, and we try to be in their alpha groups so we can be out in front of any issues. That sometimes creates an uncomfortable situation where a manufacturer has broken their Roon Ready device, and we have to make sure they knuckle down and make the fix.
GB: What are some of the problems most commonly reported by customers in help requests, and on the Roon Community?
RD: The most common issues are probably synchronizing over Wi-Fi. Like everything else, as soon as you put a wireless network in the middle, things can get trickier.
Also, Roon has a lot of cool DSP features, and these will confuse some people. Between DSD, hi-rez, DSP, and MQA, there’s a lot of esoteric language that flits around, and the underlying ideas aren’t necessarily intuitive. So we end up doing a fair amount of support around that.
In terms of day-to-day use, people sometimes call when their device does not show up in Roon. Maybe at some point there was a brownout, and the router turned off. Now the device needs to be turned off and back on, so that it gets a new network address. Simple things like that are pretty common.
Customers sometimes need help getting the most out of their device. That’s where it really helps to have the devices on hand. If we can look at the device’s menus and tell the customer how to set them, that really helps a lot. At some point the customer may have changed a setting in the device’s menu, and something’s not working.
GB: How many different devices have you tested and certified?
RD: Between our Roon Ready and Roon Tested programs, I think we’re closing in on 400 different models from various manufacturers.
GB: What are the differences between the two programs?
RD: Roon Ready is for networked audio devices. It’s like AirPlay and Chromecast, except that it’s super-high performance. As with AirPlay and Chromecast, a Roon Ready device will show up in Roon as an available audio output over the network, and then you can play to it, with no complex setup or configuration. The advantage over AirPlay and Chromecast is support for hi-rez, DSD, and MQA.
Roon Tested is a support and comarketing program. Roon works with thousands of USB devices, but early on we recognized that it’s scary for customers to buy in to something new if they don’t know it’s going to work with their devices. We were fielding daily questions asking if DAC X from manufacturer Y would work with Roon. We created the Roon Tested program so we can say that we’re working with a given manufacturer, and a given device works with Roon.
There’s also a support relationship. As with the Roon Ready program, it sends the message that if you buy this device, we know a lot about it, we have access to it, and we can work with the manufacturer if there’s a problem.
Here’s a cool example. In the last year, a really interesting problem started to come up in our support channel. All of a sudden, people who had owned DACs for a while started reporting problems on Linux, say when they’re using a Roon Nucleus server. What was happening is, as Linux updated its audio capabilities and became faster and more robust, it exposed a bug that had been there all along with a chipset commonly used in a large number of DACs. It took a while to figure this out, but we could see a pattern across a wide range of manufacturers and devices in a way a single manufacturer might not.
If a company sells 80 units of a certain DAC every few months, it’s only going to see a small window of use cases and problems. But if we’re seeing the same problem on devices from 12 manufacturers, we can pop them open and see that they all use the same chipset. In this case, we could reach out to the chipset manufacturer and tell them about problem. They said they might fix the problem when they got around to it, which is not a great answer. So we looked around, and found a freelance programmer who had developed a workaround and was willing to share it. Then we contacted the partner manufacturers, told them about the problem and the workaround, and got them to implement it. We do this kind of thing pretty regularly.
An important thing to understand in the hi-fi world is that a lot of manufacturers buy USB and networking chipsets off the shelf. Then they integrate them into their devices, and possibly customize them as well. Sometimes they’ll do tweaks to their USB chipset to allow higher bitrates, which exposes them to other issues. So we are working not just with our hardware partners, but third-party vendors as well.
There are three primary vendors who provide the networking solutions used by many of our partners, and about five DAC chipset manufacturers whose products are widely used. So we also have to work closely with those third-party vendors to make sure everything runs smoothly.
In the case of using these third-party solutions, our hardware partners never touch the RAAT software. They just customize their device firmware to talk to the RAAT software on the third-party network module. They have to get their volume control to talk to the network card they get from the third-party vendor, then that network card’s RAAT talks back to us. That’s a whole new layer of complication for these companies. It takes a whole lot of interaction between us, the third-party vendor, and the manufacturer to get a good result.
GB: Roon is at the other end of the certification process, with Apple and Google for your control apps. Are there challenges getting the Roon Remote app on the App Store and Google Play?
RD: That’s pretty simple. Apple and Google have very well documented requirements. Apple can be funkier, so it’s harder to synchronize a software release when we make major changes around iOS and Android. But Roon’s architecture is set up in such a way that we don’t often have to make huge changes to the Remote apps.
GB: Were there challenges around implementing MQA core decoding, and getting whatever certification was required?
RD: We know the MQA team really well, and we’ve watched that technology grow from its infancy. Right from the beginning, we could pass the MQA file on to the playback device. That wasn’t hard. We wanted to do the first decode, then apply DSP, and then add back in the MQB information [the MQA metadata that tells the DAC how to configure the output filter], so that the DAC could do its final render.
We wanted to do this because we never wanted the customer to have to choose between using the full functionality of Roon and their endpoint, vs. using the full functionality of MQA and their endpoint. We wanted to make sure customers always get the most out of everything they have. No one had ever asked to do this before, so it took us a little longer to add MQA decoding. But we got to the right result.
GB: What about integrating content partners like Tidal and Qobuz? Is that a challenging process?
RD: That’s a lot of work. Streaming services have their own APIs [application program interfaces] for integrating with hardware devices. But their APIs don’t allow us to do what we do, so we have to do a lot of custom work with them.
Basically, we treat the libraries of Tidal and Qobuz like a really big hard-drive collection. So we get regular data dumps from them that show all the files they have. We scan those big collections, just like we do with the audio files on your hard drive. If there’s a new U2 record and 100 people are credited on it, those 100 people all have profiles. All those profiles have to be updated, and then your Roon library metadata gets updated. Everything is getting recomputed every day, so when you do a search in Roon and it searches your local library, Tidal, and Qobuz, you get a result quickly. So the big work is the integration.
We have our way of looking at data, and they have their ways. Each company has their own specialized features -- how they handle their playlists, how they show their featured content. We want to give elements of these services’ unique experiences to our customers. So yes, this is a challenging process.
We got into this almost 15 years ago. We were just a bunch of guys who loved music and had big music collections, and there was not a good way to manage them. That’s all we’ve done for 15 years -- loving music and trying to find the best ways to manage all the music in the world.
. . . Gordon Brockhouse