Configuration and Control of a headless remote NUC with MBP Core

Roon Software Discussion
1

I’m 10 days into a Roon trial.

I am mostly very impressed with it, but there area few points where what I thought I would be able to do hasn’t worked out, so the configuration I’ve ended up with is not as nice as I’d envisaged.

I think I have figured out where I misunderstood things, and where I can get to in the future, but I’d like to make sure.

The main point of this post is some questions, they appear towards the end. I could have made the post shorter, but thought I’d set out my reasoning in case I made obvious mistakes. Please let me know if I have!

My configuration.

I completely agree with the Roon principle stated thus: “While the centralized Core does the heavy lifting, audio devices can be simpler, lighter-weight, more reliable, and less electrically noisy.”

So I installed Roon Core on a machine reasonably competent for the “heavy lifting”, but not one I want to use a lot for audio playback. A 2013 MBP retina (i7, Yosemite, 16GB memory). This works fine. I installed full Roon, but mostly I use an iPad for Control (the MBP is some distance from the audio room).

But I do a lot of audio playback through a dedicated headless i3 NUC (Windows 10), where I can run just audio software and do some OS optimizations.

Reading on the Roon website that “any Mac or Windows PC can be an output”, I figured that I could just point the NUC back to the MBP server and run the whole lot from the iPad Control. I think this is where I went wrong (see below).

So, how to install Roon on the NUC? First I tried Roon Server. As the NUC is headless, I didn’t want dependency on OpenGL. And the website tells me “After installing Roon Server on your headless machine, you can install Roon Remote on your mobile device or laptop to control Roon Server”. So I deduced (again perhaps incorrectly) that my iPad control would be able to Control the combined system of MBP Core and NUC Server.

First problem. Roon Server wants to be the unique server, it doesn’t like the idea of being subservient to another. I’d been hoping to just link it back to the core and use Outputs from both, but I couldn’t achieve that.

So I tried to install full Roon. Using my customary mode of interaction via RDP, Roon refused to start as RDP doesn’t do OpenGL. Not surprising I guess. So I connected monitor and keyboard to install it (configured as a Remote).

Surprise (big one). I was expecting a zone that I could control via my iPad. I get a private zone that is invisible to the iPad. So I can control it only via the NUC. Which is meant to be headless. Hmm.

So I found another way to get control. I made the NUC mostly headless by connecting a dummy monitor plug, so that Roon is deluded into thinking it has a monitor to talk to. Then installing a lightweight VNC server. Now I can sort of operate Roon on the NUC through a VNC client on the iPad. This is a bit quirky and clumsy but reasonably operational (basic controls are not too difficult, and I can set up JPLAY etc).

Of course I wouldn’t see the VNC method as a viable long term option. The Roon app is much nicer!

Now some reflection.

Why didn’t things work out how I hoped? I think because I got caught in a disconnect between Roon as it is envisaged and as it currently implemented.

Reading around a bit, I think what I need is RAAT and a RoonBridge (formerly RoonSpeakers), in order to provide the level of application-specific visibility needed.

Trying to be somewhat precise about the terminology (hard info is somewhat scattered ;( ). This is my understanding (please correct if wrong):

RAAT is a Roon-specific UDP-based lightweight streaming protocol for audio streaming between centralized Server and Zones (rather than Outputs?), presumably with an API for establishing streaming connections etc etc (all of which is of course transparent to someone using Roon).

A RoonBridge is a software artifact implementing RAAT. Presumably on W10 it will be an executable running a process (rather than service?) and configurable with a few parameters. I guess the RoonBridge will make visible as Outputs, in the Audio Setup menu of the Server, the various sound devices accessible via the OS.

I see that the RoonBridge is not yet available, but coming soon.

Now my main points.

So, I am hoping that when we have RoonBridge, I’ll be able to do much of what I tried to do above:

  1. That I can run just a RoonBridge on my NUC and keep it headless;

  2. That my NUC will appear as a Zone, not a Private Zone;

  3. That devices in that Zone will be selectable as Outputs;

  4. That Roon on my iPad will act as Control.

Is this corrrect?

Please correct me if I’m wrong on any of those points.

What could I have done to get a better configuration now?

Well, I could have made the NUC the primary Roon machine, running the server. But this is architecturally inappropriate, and defeats the separation of heavy lifting from audio output. I could set up Airplay on the NUC, but then I don’t have higher resolution playback. I could put HQPlayer on the MBP, and a NAA on the NUC, but that is a level of complexity I don’t want right now.

Have I missed something?

So I will stick with what I have for now, and hope that my points 1 to 4 above will become viable in the near future?

TIA for any comment.

2

Hi Andrew,

Everything you have deduced is correct and the answers to each of your 4 questions are Yes. I have been telling folks for a while now that a configuration like the one you describe will be possible “soon”. I think you may be one of the last people I have to say that to.

I hope you’ve been able to assess the look and feel of the software during your trial. You’ve certainly picked up the current technical limitations very quickly. I look forward to you updating this thread with how it all works for you in 1.2.

4 Likes
3

Install RoonServer on your MBP.

If you want to play music on the MPB you can run Roon as a Remote on the same machine as your RoonServer is on.

Wait for RoonBridge.

4

Thanks! I’m reassured that I’ll be able to use it in the way I expected.

I gather that 1.2 is just around the corner, so I look forward to trying it. I’ve noticed that it also brings internet radio, that I use a lot, and which seems to be a bit of an afterthought with some audio players. So I’ll be interested to see how that is done as well.

I like the look and feel of the software. Artist and track information is good to have, and it’s also good at exploration of related material (much better that Tidal alone). My “multiroom” experience is only between office (MBP) and audio room, but it works quite intuitively (eg switching a session from one zone to another).

I haven’t had time to do SQ comparisons between Roon and the audio computer I built, or with other players. Signs are positive though - I haven’t felt a compulsion to turn it off after a few minutes!

As I have to travel interstate for a couple of weeks from Friday, I’ll probably cancel the trial then and pick it up when I return. I strongly suspect that having become used to it, I’ll have trouble being without it!

5

Thanks. I’ll look into that.

6

Returned from holidays and installed 1.2 and Roonbridge yesterday.

Looks good, and have had it running for a few hours last night. Initial impressions are favourable, and it works fairly much as I hoped.

However I did have an interesting experience in getting Roonbridge installed, so I’ll mention it here in case the information is useful.

After installation, the NUC outputs were immediately visible in the Roon server. Very good.

I set up and named the first without problem. There was another for JPLAY, so I attempted to enable that. This caused a long pause, after which my NUC outputs disappeared from the Roon server.

I figured there must be a configuration problem, so restarted Roonbridge. No luck, so closed it down and tried to uninstall and reinstall it.

There were some messages about RAATServer from the uninstall script, but these went away on retry.

However the reinstalled Roonbridge behaved strangely. RAATServer was attempting to start every minute or so but terminating with an exception (visible in system logs).

So I checked the Roon files in local\AppData,and found that the RAATServer directory was still present from the original failed installation.

I deleted that directory, reinstalled with just the first output, and all was fine.

I guess the failed original installation had left a corrupted device file in the RAATServer directory, causing subsequent problems.

I presume it is intentional that this directory persists through re-installation? Nonetheless, it is something to keep in mind if you want a completely clean re-installation from scratch.

There was a version update overnight, so I re-tried the JPLAY setup. This time it worked. But it is still the case that the RAATServer directory survives un-installation, so in the rare event of a crash while enabling a device, the above scenario could presumably occur.

7

Thanks Andrew for that update. Pleased that it is working for you. There are inevitably a few glitches associated with a release of the magnitude of 1.2 that slip through testing. The next few bugfix releases should bed everything down tight.

I’ll drop a flag for @mike and @brian regarding the persistence of the RAATServer directory as it sounds like something they should know about.

Happy listening !

8

Hey @Andrew_Wendelborn,

Thanks for your feedback. Happy to see that you were able to set things up. As for the RAATServer failures - indeed, there was an issue with RoonBridge package, and it was failing in the way you’ve described it. This issue is fixed now.

Best Regards