ROCK - Strategies moving forward

I know I’m a bit late to the game here, I apologize for not constantly combing the forum here, but I just read about ROCK and have to say I’m a bit surprised that Roon is undertaking this effort. It appears that you’re taking a stripped down Linux distro, adding necessary drivers and creating an easy user interface to setup a Roon Server as far as I can tell – all because you’re trying to minimize customers having installation issues on the myriad of hardware they run. (please correct me where I’m wrong).

Just a few thoughts:

The thing is, you seem to be spending a significant amount of time creating ROCK and supporting it, and it’s not even released yet. In my humble opinion, I think you’re going to create even more customer support requests specifically on ROCK installation, troubleshooting, maintenance, etc. Not to mention that the platform (the Intel NUC 6iyxx) is not far from being replaced by Intel (and trust me, that platform is a real pain when it comes to USB/Thunderbolt drivers).

I read in another forum that you could charge for this service, and quite honestly I think you should just do so and sell a whole turnkey NUC and be done with the customer headaches. That way the hardware/software issue will be done with and you can focus on making Roon great.


Interesting point of view. I do not necessarily disagree but.

Let’s look 6 to 12 months ahead, and even more.

We do not know the Roon roadmap, but if we make a guess how about a scenario similar to what’s happening on the TV side.
Apple and I think it was yesterday Google announced YouTube TV.

It does not take a master mind to think Roon like to invite all present and future Content distributors and do something equal.
Also it’s not a secret that some of these guys are quite reluctant in supporting Roon. For reasons I do not know.

I would never expect Roon to support Sonos. Now they do, even though Sonos has HW limitations on present product line.

I’m also under the understanding that they may include HQPlayer up-sampling and filters, or at least the option to control them.

Further several HW manufacturers support and benefit from Roon and their RAAT. (and Roon Brigde)
At the moment we thinking about DAC as HW, but I would like to add NUC, and then other computers based on that Intel design.

So mabe by “controlling” the whole chain also can make some sort of HW (read computer) acknowledged/approved HW, like from small companies like SMG and Sonore. Cause I myself is a bit skeptical to a NUC with fan and other noisy elements vs some audio tweaked HW. Like better regulators, clocks or what ever is possible to do.

I do myself have zero Linux knowledge but I’m under the impression this is most likely best audiophile SW.
If I’m right so many DAC’s and CD’s are based on some sort of Linux, and you are normally stock with that HW, even if some SW upgrade could make your gear better.

If Roon can develop some sort of the “Ultimate Audio Linux”, it may be a better solution and a win/win situation.
HW manufactures can specialize on making perfect HW, and Roon making perfect SW :slight_smile:

And I would not worry about the support issue, Roon has the best support I’ve ever seen. They are around 24/7 cause I think the team lives around in different timezones. Their site this one, is the best SW solution I’ve ever used. At least the only one I understand how to use :slight_smile:

So actually the need of support may be less, cause of the professional way this is handled. Some of the users will be so much up in front with the technology that all issues will be solved before its a problem.

So in one way Roon may be a world leading company in how things can be done.
Time will tell who is “right”.

ROCK offers the best of both worlds to Roon. It offers a hardware solution which they know intimately without the responsibility of having to look after it. If it really is dead simple to install and requires no skill then every fix will be simple. Reinstall. Minimal support effort. If that fails then it is hardware and hardware is the retailer’s problem and not Roon’s.

The OS was built from scratch–we didn’t strip down something pre-existing, nor did we use something off-the-shelf like Yocto.

We have been doing this kind of thing for many years. Sooloos appliances were built the same way. OS’s built this way are much more manageable and much lighter weight. We have good, efficient processes for managing this sort of thing. It was less of an investment for us than it would have been for most people trying to do the same thing.

The main motivation is not easing installation/support issues. That’s just a nice side effect.

You’ll notice that we like to keep some parity between the technologies we offer to partners and those that we offer to the community. One example–Roon Ready + Roon Bridge. Partners get some lower level tools for building RAAT devices that enables further customization, but they are substantially the same.

The Roon API is also part of this. There’s no “secret” API for partners. And we made sure that Roon Bridge + Roon API has no feature gaps when compared to the SDK we give to Roon Ready partners. The DIY solutions are less turnkey, that’s all–once set up, the user experience is the same. Synchronized volume control, convenience switching, metadata displays at the playback device, etc.

Like those examples, ROCK is the community-facing version of RoonOS.

RoonOS is bigger than ROCK. One example: Merging’s NADAC player (released at CES in January) is RoonOS based too. They won’t be the last.

There’s more to this too, but not all of it is something we’re ready to talk about yet…

The installer asks two questions: Which drive to install on, and “are you sure you want to wipe it?”. It’s easier than installing Windows.

Troubleshooting is MUCH EASIER because we have a variety of NUC models in-house and can match the setup where a problem occurs exactly.

There’s also a parallel to our handling of audio gear here–the Roon Ready and Roon Tested programs are powerful in part because they give us access to the gear. We put a lot of effort into building these relationships, convincing companies to let hardware samples live with us long term, and actually working with them during QA, and support.

If someone has an issue with a product that we have in house, we plug the gear together and find out what’s up. Reproducible bugs get fixed. Difficult remote troubleshooting situations with hardware we’ve never seen have a lower hit rate.

Maintenance is easy too. RoonOS uses the same update mechanism as all of our products–updates can be confirmed from any Roon control point just like Roon/Roon Server/Roon Bridge updates. The update system totally re-flashes the OS, just like a firmware update in an appliance–so it is not very error prone, and also discourages tampering (since the next update will blow that away). We have efficient processes for rebuilding the system to pick up updates to kernel, libraries, etc.

We’re not limited to 6th gen NUCs. Other NUCs work too. We intend to keep RoonOS up to date over time.

I wouldn’t put a NUC in a critical listening environment, but there’s nothing wrong with using one as a core so long as it’s isolated properly.

The NUC is just another data transmission device in a long line of data transmission devices (going all the way back to your Router, ISP, CDN’s, TIDAL, etc). Its clocks don’t matter unless you use local S/PDIF or HDMI outputs. Mechanical noise doesn’t matter if you stick it in a closet away from the listening environment.

Isolating audio gear from RFI/EMI is important regardless of anything else. This is why high quality power supplies and tools for filtering/isolating ethernet, USB, and line power make a difference.

Implicit in that is the idea that you’re isolating your clean audio environment from the outside. You know–all of the stuff running at your neighbor’s house. The refrigerator. The air conditioners. The wall-warts plugged in throughout your home. They’re all wired to the same place in the end. Inside the electrical box in your basement are a few big copper bars that connect everything together…

There is no harm in putting the NUC “outside” with the refrigerator and A/C, and it’s a lot cheaper/easier than optimizing it for membership in the listening room. The place for isolation is wherever the power and ethernet lines enter your listening environment. On the other side of that boundary there are un-controllable elements much more significant than a NUC.

In closing…

Running Roon as an appliance is a great experience–regardless of whether you buy an expensive hardware product or bring your own hardware and use ROCK.

ROCK is a way to enable our users to have a Roon appliance experience without paying for an expensive piece of hardware, just as Roon Bridge provides RAAT without requiring the purchase of a Roon Ready device.

Roon is expensive. Part of the implicit contract of making a premium product is that we need to continue to add value and improve the experience. This is one of the dimensions on which we are doing that.


Thanks for the detailed response. I think I now understand what you’re doing. ROCK is part of a larger plan/ecosystem that you’re trying to build out. The more you give away for the sake of compatibility and properly documenting your API’s, unlike say Sonos, you’re likely to get other manufacturers to make compatible gear. Are you going to support other architectures for ROCK? Atmel/ARM/8051, etc.?

No current plans to do that. Roon Core is too resource-intensive for the vast majority of what’s out there in the ARM world. By providing packages that allow running the Core in those places we are inviting a deluge of people trying to run it on $8 friendlyarm and $35 raspberry pi boards. Even if it works for some in the short term, they will have growing pains as we continue to develop the software. It’s bad for the long term health of the product/ecosystem if we are worried about breaking a sizable group of people every time we add a feature.

When the common, commodity ARM boards are matching Core i3 performance levels (not just CPU, but also signal processing performance, I/O bandwidth for networking/disks, support for PCIe flash storage, etc), there’s an interesting decision to be made. I think we’re still a couple of generations away from that. For 99% of people ARM still means something really economized still.

It’s more imaginable that we might do a Roon Optimized Bridge Kit on ARM. The big problem with that is that supporting a variety of ARM platforms well would require dedicated staff just to keep up with the pace/variety of that world, and it’s not clear that that effort would pay for itself.

Each ARM platform has its own kernel/boot-stuff/inconsistencies/patches/blobs. Lots of builds to maintain and keep up to date and new platforms coming out every few weeks. At the moment, the best option for a relatively turnkey experience running Roon Bridge on an ARM SBC is to use DietPi.

1 Like

Setting up DietPi with RoonBridge was a simple same day experience. From ordering at Amazon in the morning, delivery by 8 pm, and installation by 10 pm.

Mind providing me a URL to the info on the Roon forums here on this? Sounds interesting in the least.

The thread has become near-tragically long, but the first post has the general instructions.

1 Like

It’s become even simpler since the first post, and RoonBridge is fully integrated into DietPi in the software install menu. This can all be auto-configured with a simple txt file.