I migrated my Roon install from Roon being just another service running on a general-purpose Linux server at home to a ROCK install which owns a NUC.
For the most part, I’m glad I did. The interface is mostly snappy, playback is mostly reliable, I like the idea of having our core audio server Roon in an environment where it isn’t contending with other stuff for resources and has system buffer pools optimized for it.
But… there are a few niggling infelicities which I assume could be fixed with beefier hardware.
For one thing… while using the earlier install, I put all the RAAT zone playback devices in their own dedicated VLAN, accessible via a dedicated Ethernet port on the server, while also allowing access on the main LAN via another Ethernet pot. I was pleased to find that RoonServer would indeed listen on both ports, and that way one of the server’s interfaces is used just for Roon audio traffic, nothing else contending with it.
I was pleased to find that ROCK will support multiple Ethernet interfaces as well, so I used the Roon NUC’s hardware copper Ethernet interface for the audio VLAN and plugged in a USB NIC recommended here to use for the Roon user interfaces to connect over. That worked fine… but the USB network connection would stop working every week or two until it was unplugged and plugged back in. Lesson highlighted: USB networking isn’t infrastructure-quality.
So… I figure, there’s WiFi hardware BUILT INto the NUC. I fired up the WiFi interface and used it as the control/UI point of contact for RoonServer on the NUC. Good news: that connection doesn’t go to sleep once a week or so. Bad news: desktop or tablet Roon user interface programs lose contact with the Core while I’m doing the periodic file sync from my master repository storage of the audio files to the ROCK-advertised share of ROCK’s attached audio-storage disk. The WiFi (a pretty good setup, with an access point close to the NUC with a clear line of sight) just gets swamped, in a way I don’t believe copper gigabit would. Lesson highlighted: WiFi networking isn’t infrastructure-quality.
As for the available CPU grunt on my little 7th generation i7 NUC? It’s coping admirably well (I think ROCK is a really nice lean efficient platform), but I keep bumping up against its limits – whether transcoding some high-rate DSD material I’ve accumulated to PCM for DACs which can’t eat DSD, or trying to experiment with upsampling stuff to DSD (the latter not strictly required for perfectly happy daily use), sometimes the system runs out of steam. And I plan to get busy measuring and setting up room correction for several rooms; I suspect that running that DSP for several different rooms being played to simultaneously is probably expensive.
And I recall reading somewhere that Roon likes to assign the pipelines for distinct zones to distinct CPUs if possible. I wouldn’t mind having enough full CPU cores to allow that for all the zones in our home (currently six, could possibly increase).
Oh, and I’m not completely sold on the idea of storing the music for ROCK on an external drive. I don’t think of those as… yes, infrastructure-quality.
So it’d be great to be able to stick an SATA disk (or two?) inside an enclosure and have ROCK recognize and use it / them.
So, what I’d love to know about is:
A motherboard which:
- will take a current-generation high-end Intel desktop CPU
- has at least two onboard copper gigabit interfaces supported by ROCK drivers
- has at least two onboard internal SATA interfaces supported by ROCK drivers, for audio files
- supports at least one M.2 NVMe SSD, for the OS and Roon database
…and whose ROCK driver support isn’t likely to be jettisoned in later versions.
Is there a known-good motherboard like this? Because if so, I’ll jump right onto building a machine around it.
(Oh, and is there some other requirement in addition to my little bullet list above which I’m brainfarting on ans should have included?)