Comments on: Virtualizing Roon Server – Part 2

By: John Reekie

John Reekie — Fri, 14 Feb 2020 13:34:48 +0000

“I guess my last question is: now that all the experiments are done, what are you gonna run RoonServer on?”
Well, after all this time 🙂 I’m still using the virtualized RoonServer. I suppose because it’s fine and my library was already fully indexed.

By: Jacques Distler

Jacques Distler — Sun, 22 Dec 2019 05:42:40 +0000

I was gonna say that containerization seemed the more natural route, for this purpose, than virtualization. But, since I knew you were headed towards virtualizing Rock …

Anyway, it’s good to see that, containerized, your Qobuz results are more in line with mine. My internet connection is 200Mbs down/10Mbs up, which might account for the faster download times.

I guess my last question is: now that all the experiments are done, what are you gonna run RoonServer on?

By: John Reekie

John Reekie — Sat, 21 Dec 2019 12:43:27 +0000

I added some graphs above when running Roon Server in a container, which doesn’t have the VM overhead. The download time is about a factor of 5, which seems like it could be reasonably be attributed to download speed. After that, it’s about 4, 8 and 10%.

By: Jacques Distler

Jacques Distler — Thu, 05 Dec 2019 17:47:22 +0000

There is one important difference between playing local tracks and tracks from Qobuz. For local tracks, Roon buffers 30 seconds worth. So there’s a little spike in disk access every 30 seconds (like clockwork!), as Roon reads the next chunk of the file.

For Qobuz files, Roon caches the whole track at the beginning (big spike in network traffic at the beginning of the track, then nothing till just before the next track starts).

By: Jacques Distler

Jacques Distler — Thu, 05 Dec 2019 17:24:43 +0000

I queued up your 3 tracks, waited till Roon quieted down (it’s been pretty busy this morning, doing SOMETHING, even without my playing any music), and then pressed play.

With the first track (16/44.1), there was
* a spike to ~140% which lasted about 6 seconds, then
* Roon used ~5% for the rest of the track (with the usual random spikes)
With the second track (24/96),
* a spike to ~140%, which lasted about 12 seconds, then
* Roon used ~9% for the rest of the track (with the usual random spikes)
With the third track (24/192),
* a spike to ~140% which lasted about 8 seconds, then
* Roon used ~14% for the rest of the track (with the usual random spikes)

So I’m definitely seeing (the familiar phenomenon) that high-resolution tracks chew up more CPU. But, aside from the initial spike (which is usually only about 2 seconds, for a local file), I don’t see any difference between the sustained CPU usage when playing a Qobuz file versus a local file.

In the settings, you can cap the resolution sent by Qobuz (I usually keep it at 2/96, but removed the cap for this test). If you do that, then the CPU usage is reduced accordingly.

By: John Reekie

John Reekie — Thu, 05 Dec 2019 12:42:01 +0000

Hah hah, profligate indeed! Thank you for trying that, that’s a very interesting result. Perhaps a combination of download speed and file size, the latter seems inconsistent. I’ll try some more tests, in the meantime here are the tracks I used:
https://open.qobuz.com/track/1755947
https://open.qobuz.com/track/63522440
https://open.qobuz.com/track/53971256

By: Jacques Distler

Jacques Distler — Wed, 04 Dec 2019 20:56:11 +0000

I have a very different experience streaming from Qobuz. There’s a brief (~2s) spike at the start of each track (to ~160% of a core). But then the sustained CPU usage is no different from playing a file from my LAN.

I am curious to know the reason for the disparity.

* It could be because my music is remote-mounted from a NAS, rather than residing on a disk on the Roon Core machine.
* It could be because my broadband connection (236 Mbps) is faster than yours.
* Or perhaps it’s an artifact of your assigning only two cores to Roon during this test.

Would be good to know which.

More broadly, I really appreciate this series of posts, even though they do jumble together two separate matters for investigation.

1. The benefits of virtualization
2. Using netdata to explore the performance characteristics of Roon Core

Of course, you need to do the latter if you want to configure the VM correctly for running Roon. But it’s also of independent interest to those of us profligate enough to consider devoting an entire Odroid H2 to running Roon.