Does anyone run Roon Core and Bridge as a Virtual Machine?

Does anyone run Roon Core and Bridge as a Virtual Machine?

The use case: Multi-room Audio. Here is one machine running, both, Roon Core and a number of Roon Bridges. The Bridges connect to hardware USB ports or hardware sound cards. The output goes to the Digital to Analog Converter (DAC) of choice. The DAC’s analog outputs plug into a multizone amplifier.

What are the benefits and drawbacks here?

Thank you.

I run ROCK in a VM using ESXi as hypervisor. No drawback. All my endpoints are in the room where the sound happens across hardwired ethernet.

I think the drawback of running in the configuration you’ve identified is you won’t have the cleanest path from bridge to DAC to amp resulting in reduced SQ. Maybe that doesn’t matter in your multi-room setup. But a hypervisor running multiple VMs is just generally going to be noisy. The USB bus will be noisy. It’s the wrong place to start for excellent sound quality. Could you actually here the difference? If you were using lower end ceiling speakers with no attention to imaging then no. If you’ll be using that set-up for a reference listening sweat spot then absolutely. Of course, nothing stops you from doing a combination of virtual bridges where it doesn’t matter and setting up a much higher quality endpoint where it matters.

I do like this idea though. Been talking to a friend of mine who is building a house and we’ve been discussing possibly using Roon as the source of his whole home system. He’s trying to do it on the cheap so one idea we were playing with was Rasp Pis with amp hats. Looks like we can drop as many Rasp Pis as we need cheaper than a multizone amp.

Anyway, looking forward to hearing more details of your final setup and lessons learned.

1 Like

Good points. I just don’t have a test method to measure the noise.

I have considered the RPi with HATs. I also considered iOS 11/Android 5+ device as the endpoint.

Using the mobile devices you get a touch screen, battery back up, and good product all in one. Just add a Dragonfly Black an Amp w/ speakers.

Back to the all in one solution, the design aims to have all devices in a rack. A central solution connected to speaker wire and speakers in room has a benefit of reducing the electronic and wiring clutter in each room.

Just curious… what’s the point of running several Roon bridges on the same machine? You can already have several audio devices per machine and link them however you want during setup. For instance I have three DACs connected to my machine where I run core and bridge.

The comment regarding noisy USB port is snake oil, but you will run into issues with latency spikes on a VM on your core and bridge that could cause issues. If you really do want a bunch of bridges just use docker. But I still don’t understand the use case here.

Good question. I realized that, what you mentioned above, last night when I ran Roon from machine that has multiple sound card drivers. They were all presented to me in the audio set-up.

I was thinking in terms of fail-over or failure of an endpoint. If all was virtualized , it would have a redundant VM to keep the music going. Overkill- yes.

I wanted to know if the group found any peculiar advantages.

So, the failover won’t actually be automatic though since Roon bridges require exclusive access to an audio device. Moreover, since each endpoint has its own bridge, it’s actually worse now in that you’ll need to identify and then manually restart one of those bridges.

If you’re running a single bridge eg; as a systemd service, the service will automatically restart for you in less than a second if it does happen to fail. Moroever, by running a single bridge you get much better performance since the CPU scheduler in the kernel is able to better manage vectorized workloads (things like convolutions are vectorized operations that require special CPU instructions that can disrupt other workloads on the VM).

All you’re going to get is increased latency by running a bunch of VMs. In fact, even amazon is going down the route of providing bare metal instances (or using very low level hypervisors that provide exclusive hardware access) due to the disadvantages of VMs.

If you do want multiple running bridges for whatever reason then use docker. There’s no virtualization overhead and the network hit is very minimal (order of microseconds).

1 Like

Very insightful. Thank you.

Based on your feedback. I’ll consider running a Windows Guest with Roon Core and have a separate hardware machine (RPi/Windows Bridge) with 3 DACs/outputs going into a multizone amp combination.

And for what it’s worth, you’ll also get far better performance running the core in Linux from what I’ve seen. It’s much lighter weight.

Cool. I’ll give it a go!

I run Roon core in a Linux 18.04 container on Proxmox VE - open source and awesome. Proxmox hosts a bunch of other containers including my Plex server etc. and it is rock solid. It is sitting on an old ex-Lease Dell 9020 desktop that I picked up for a few hundred $ and sits in the basement. I never need to touch it as it is all administered via the Proxmox Web GUI from any device on my LAN. My library is on a Synology NAS connected to the Host with gig LAN.

I’ve had no latency issues at all controlling/syncing 5 Roon end points with MQA/high res audio, some of which are wireless - so I’m not convinced latency is a concern.

The main advantage of running things this way for me is, in addition to having Roon on a dedicated always on platform, that it is incredibly easy to administer/change/upgrade/restore - ideal if you are a tinkerer.

  • Say you want to try a new Roon extension or somehow tweak you Roon system, but don’t want to bugger it up? Duplicate your Roon core container in Proxmox (about 60 secs), boot it up, and tinker away without fear.
  • Say you do irretrievably screw up your Roon core because, like me, you don’t really know what you are doing? Nuke your old Roon core container and restore it from one of the daily snapshots that you scheduled Proxmox to make. About 5 mins and you are back up and running.

It’s great.