I’m new to roon, so this is going to sound a bit presumptuous… but I have decades of experience as a system architect on large, mission critical systems, parts of which had near real-time constraints, so maybe this perspective is useful.
I have a very large (> 10,000 album) music collection. I’ve used many music management/playback systems, and only a couple have scaled adequately. Roon has done an excellent job with database. I last used a system I’ll call S1. I liked it a lot, but hit a scalability wall. The user interface became very sluggish: sometimes it could take several seconds to respond to a control input, even as simple as “pause playback”. But even at its most sluggish, it would continue to play the current track without glitches or interruption. I could re-index my large collection without interfering with playback in progress (though the user interface response suffered greatly).
So, how about roon? first attempt: did a trial with the following setup:
Core:dell inspiron laptop, 64 bit windows 10 - dedicated to roon.
WINDOWS-HCUU2NA, 64 bit
intel core i5-4200U, 1.6 Ghz, 6 GB RAM
Music repository: smb mount from pi4 dedicated fileserver
network: switched 100/1000 ethernet, cat 6 cabling and linksys/intel switches
ROPIEEE bridge running on Raspberry Pi 4 Model B Rev 1.1
The ROPIEEE sw version is 3.094, kernel 5.4.83-5-SPCKFSH-v7l+
output: Benchmark DAC3 HGC, usb connected to the pi/ropieee bridge (no HAT/daughter board)
control: android tablet and various
I realized the core was likely underpowered, given my repository size. the fileserver DAC and network were well tested over a couple of years of previous use, including hours of DSD playback. I expected sluggish performance. In fact this setup was completely unusable. playblack often stopped within 20 seconds of initiation. and system activity caused the client to lose connection to the core.
so, second attempt: ROCK on roon labs suggested high end intel NUC10i7FNH with 1 TB M2 SSD:
core: As stated above, NUC hardware, roon optimized core kit, server Version 1.8 (build 790) stable, OS Version 1.0 (build 227) stable
network and fileserver: same as above
Same benchmark DAC, but no bridge: DAC connected directly to NUC via USB.
control: same android tablet
This system is fast to respond and has performed flawlessly once my large collection was imported. focus and search are fast.
So (if you have made it this far) - whats my message? Roon is a great system with a leading approach to database, but some basic architecture work could improve performance when there is resource contention or the system is overloaded. My previous to roon system (S1 above) did not scale because of poor database design, but even under severe overload it continued to play music well. To me, when I push “play”, we should have a contract. However busy the system becomes, playback should not be affected: this is a “near real time process with hard time contraints”. background processing, audio analysis, database updates etc - let them slow down or pause. S1, whatever its limits, managed this. With all its sophistication, roon should too. When resources are overloaded, its ok to slow or halt background, including slower user response, but loss of core connection and interrupted playback should not occur. My initial roon system had enough resources to get bits from the fileserver to the DAC, and should have done so under load/resource constraints, no matter if other processes had to suffer.