Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
Using bridge network invirtual machine
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
LUMIN T2
Chromecast ULTRA and AUDIO
GOOGLE MINI
Description Of Issue
I was previously running the Roon Core on my i9 based desktop on Windows 10.
I read about @Lorrain_VIVRAY testing ROCK on vitual machine using VMWARE PRO and I thought I would give it a try because I believe ROON is developping better functionality and stability for their own hardware set up.
I tried first with HyperV but there was an issue with USB passthrough (using PLOP boot manager to install ROCK from usb stick); then I tried VMWARE PLAYER free but it start by default on SCSI hard drive which is not compatible with ROCK; I could install on second virtual SATA HDD but could’nt find how to change easely the boot sequence to boot from the SATA HDD instead; so finally I decided to use VIRTUALBOX; there I could install completly ROCK, but I could not access DATA from the Windows HOST explorer to install the ffmpeg codecs; so I created an Unbuntu virtual machine from which finally I could access the ROCK data folders.
Whatever ffmpeg file I copied in the Codecs folder and reboot the ROCK, the web GUI was still showing in red “missing codecs”.
Hi @mentalfloss, did you try ROCK as virtual machine directly?
Proxmox looks attractive but I would only move if I could implement ROCK directly, not Roon Core in Linux.
I was able to make it run in Virtualbox and copy the ffmpeg file in the codecs data folder, but the instance is still stating missing codecs. Otherwise working flawlessly with flac and streaming Qobuz. I still have some mp3 in my library so would be willing to resolve the issue.
I get the feeling that Roon is making ROCK very efficient because of Nucleus and I am not sure how much this is reflected in Roon Core for Linux…
I had open a ticket in Support but it was moved to Tinkering by a moderator, because this way of applying ROCK is not supported by ROON. Here it is:
I have resolved my issue and now my VM machine is fully functional with Codecs working.
I am copying the ffmpeg file from a Linux VM to ROCK VM and previously was connected as anonymous to the SMB share. Althougth the file was looking like copied, ROCK did not took it in account.
This time I connected to the SMB ROCK share using my Windows Host account details. I have copied the ffmpeg file and this time ROCK took it in account and I am all OK with all codecs installed!
No, I chose to run Roon core on Ubuntu 18.04 server in a Linux container as it shares resources in the host so is lighter on resources in the host vs running a full VM (and I have a bunch of other containers). But I’m keen to have a tinker with ROCK. I might try it in Proxmox and report back.
EDIT: Actually, now I look at it, installing ROCK this way sounds like a distinctly bad idea. It is very much optimised around installation on an Intel NUC, and trying to make it work on a VM seems like a short road to a whole lot of unnecessary pain. The standard Core works perfectly well on Linux in a container or VM.
Thanks for this. Just to confirm that ROCK is working perfectly well in Virtualbox VM in my system. For instance I made the latest OS upgrade without any problem.
The ROCK VM should be even more optimized in ressources than Linux + Roon Core VM, as I understand it. My ROCK VM is using the host network card in bridge mode. The library drive (4To) is a shared drive from the host. The same for back up locations.
I did set up another virtual drive attached to the ROCK in case I would want using the ripper feature but for the moment I don’t have time for this to test and would probably stick using DBPoweramp in the Host desktop anyway.
Cool. But I’m not sure what you gain doing that way as it will require a full VM rather than a container. A full VM has to exclusively own its resources e.g. RAM. And I’ve learned the hard way that using software not as designed punishes you later.
Standard Roon core on a basic Ubuntu server (no GUI) is light on resources and performs perfectly well. And it won’t make a jot of difference to sound quality. So it seems to me that installing ROCK on an unsupported platform is just asking for pain for no gain… that said, I fully appreciate the desire to tinker…
Also, now I think about it I’m not sure running the standard core on a hypervisor is supported either! So who am I to talk. But I still think it is less likely to cause you heartache installing the standard core (which is designed for a generic linux platform) on a virtual machine than installing ROCK on a VM which is specifically tailored to an Intel NUC.
I’ve been running ROCK on ESXi (free) for a year without issue. I have a 1U server with 32GB and plenty of cores for all my VMs. Containers are great but would add significant complexity to my environment (as example, I use the virtual network layer in ESXi to attach virtual NICs to VLANs for isolation). I don’t mind dedicating resources to ROCK instead of “sharing”. That’s obviously a different philosophy but it works for me. The other nice thing is that I never worry about upgrades within the ROCK path. There is no concept of a “node” which needs to be maintained. ROCK takes care of itself. If I was managing a ton of microservices I’d certainly transition to a container architecture but honestly I just don’t have that much to maintain at home. In my current set-up I can upgrade and reboot every “Linux install” on my server and ROCK is never interrupted. That cannot be done with containers unless you’ve got multiple nodes and the containers can be fronted by a LB (which ROON cannot). While I love the enthusiasm I see for loading Roon as a container… it just won’t work in all environments. For that reason loading ROCK in a VM makes a lot more sense if you’re not wanting to drop another bit of hardware into the environment. And, on top of all that, the money I saved by not buying a NuC went directly into a lifetime sub and I’ve got 99% of the NuC benefit (with faster cores).
One other bit I wanted to mention. “Sharing” of resource in ROCK I don’t recommend. I don’t have a routine for listening nor do I always listen to the same zones. Some of my zones I use upsampling. Some of files need DSD (multi-channel) -> PCM (2-ch) conversion. Additionally, there are others in my house who use Roon. Without routine this means I may be listening at the same time I’m hammering another VM or multiple VMs. I get consistent, predictable, performance from ROCK regardless of what my other VMs are doing as I’ve dedicated resources to ROCK. I can drive all my other VMs into the ground and I never hear from a family member that “somethings wrong with Roon”. That’s a priority for me and has worked consistently over the year. Again, a different philosophy to how to run Core.
Anywhoo… just wanted to throw an alternative “why” out there.
Great post. Interesting that it is so stable - clearly ROCK is not that fussy about not being on a NUC which was my main concern.
I take your point re not having Roon impacted by other services. That hasn’t been an issue I’ve struck. The only likely culprit in my environment would be the container running Plex if it were busy transcoding something - but in our house it is unheard of that Plex and Roon would be used concurrently.
Yes I do have 2 nodes in my environment so can avoid downtime - but TBH I don’t bother migrating Roon or other services when doing maintainance unless it’s something major. I can put up with the occasional complaint from my users (one of whom is 10, the other 6 )
ROCK on Proxmox is still something I might have a play with. But currently it’s mainly a case of if it ain’t broke don’t fix it.
Ok I think I have understood the context of this thread and want to jump in, but with one major addition.
Currently my ROON core is located on a dedicated AMD laptop running windows 10 -very much bare bones. The output digital signal into my DAC via USB.
I want to create a Virtual Box on a RAMDISK and install ROON Rock there.
But I see a flaw during boot as ROON Rock will not yet be retrieved from the HDD for the boot process to commence.Will it just be a delay or will the boot fail?
This is kind-of interesting. I experimented with something similar…running Arch Linux as a VM in VirtualBox and then installing Roon Server. It performed better than expected on my 7th gen i5 Intel NUC with Windows 10 Pro host O/S.
But, I’m much more interested in running Roon Server in a Docker container with the new WSL 2 kernel. I’ve just started tinkering with this (there are other threads here that discuss this in detail), but a containerized Core will make much better use of the underlying hardware.
Even so, I would avoid directly connecting a USB DAC to a virtualized or containerized Roon Core. In fact, I assiduously avoid connecting a DAC to any machine that is running Roon Core or Control, but that may just be me.
I use ROCK on virtualBOX, sound is better than on same windows pc using “windows roon server software”
To boot from rock img, you need to convert rock IMG to VDI
“VBoxManage.exe convertdd roonbox.img roonbox_vm.vdi”
Then put new VDI as a SATA disk in VM
Install ROCK (also need put usb keybord in VM)
Remove VDI with rock img
Run VM, in windows explorer go to \ ROCK\ and copy codecs
restart ROCK
Work perfect !!
roon bridge : RPi4 (RoPieee) USB ->Gustard U16->Audio-GD R2R 11
Hi @RoonFan_Neil, I am building a new NAS but waiting without delivery visibility date for SSD NAS drives. It is a QNAP TVS-h1688X so plenty of horsepower for VMs among other things! I will follow your instructions and report…hopefully still in 2021! Thanks for the work anyway and the other valuable inputs of others in that topic.
You don’t need to plug in a second keyboard in order to operate ROCK, you only need to change the virtualbox’s emulated keyboard from ps/2 (default) to usb.
Also, in order to free the mouse you only need to press the right Ctrl key, no need for ctrl+alt+delete
