Just shoot me now.
I installed a second hard drive in the machine that hosts my files. I installed Ubuntu Server 16.0.4 on it Installed RoonServer and practically nothing else. Then I mounted the original hard drive as a data drive. It’s at the same mount point in both OSes, so I didn’t have to reconfigure a ton of Samba stuff.
And it fails. But a little differently now. Now I’m seeing failure to noise followed by an interval of music, failure to noise for a while, then music again for a while. Seconds, a minute or so tops.
Now this machine is not very powerful, compared to the Fedora machine on which I’ve been trying to run RoonServer.
[root@asok ~]# lscpu
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 2
Vendor ID: AuthenticAMD
CPU family: 15
Model name: AMD Athlon™ 64 X2 Dual Core Processor 3800+
CPU MHz: 2008.927
L1d cache: 64K
L1i cache: 64K
L2 cache: 512K
It has only two gigs of RAM.
At first, I was getting noise on both 96K and 192K files. I had the data mounted via CIFS. I changed that to a local file system mount and things improved a little, to where 96K files play alright, but no change at 192K. This felt like lack of resources to me, so I tried lessening processor and memory load a little by turning off background processing and reducing memory reserved for pictures in Roon. Might have helped a little, but didn’t resolve the issue.
I tried setting bit rate limiting. If I limited the bit rate to 48K, my 192K file played perfectly. Despite the increased processor load, go figure, right? Limiting bit rate to 96K didn’t help - same pattern of failure and music in intervals.
Whether playing a 192K file, a 96K file, with bit rate conversion on or off, system load looked like this:
root@asok:/home/carl# ps -aux | grep RoonServer
root 2003 0.0 0.0 12540 1900 ? Ss 16:35 0:00 /bin/bash /optRoonServer/start.sh
root 2009 0.0 0.4 544288 13920 ? Sl 16:35 0:01 /opt/RoonServe/Mono/bin/RoonServer --debug --gc=sgen --server RoonServer.exe
root 2020 80.5 33.6 1762752 1036668 ? Sl 16:35 80:05 /opt/RoonServe/Mono/bin/RoonAppliance --debug --gc=sgen --server RoonAppliance.exe -watchdogport=33452
root 2027 0.0 0.0 7328 780 ? S 16:35 0:00 /opt/RoonServe/Server/processreaper 2020
root 2050 0.0 0.2 830992 8836 ? Sl 16:36 0:03 /opt/RoonServe/Mono/bin/RAATServer --debug --gc=sgen --server RAATServer.exe
root 4262 0.0 0.0 14228 980 pts/0 S+ 18:15 0:00 grep --color=auto RoonServer
That’s CPU hovering just under 80% and memory at about 30%, give or take a point or two.
Now as I write this, I’m playing to an Oppo HA-2, through my laptop as a Roon endpoint, and a 192K file plays perfectly, with a nice purple “lossless” signal path. Which suggests to me that the meager power of this server machine isn’t really the issue. UPDATE: I just checked and indeed, streaming to the Roon endpoint does take less CPU - 56.6%, compared to ~80%. Memory use is actually up a little, at 33.4%. Hmmm. But before I get excited, I remember the Fedora machine has ample resources.
I suppose I could go back to one of the virtual machines and cut back memory and CPU capacity in increments until it fails to see if I can make the same failure mode.
EDIT: If I could make Roon fail on a VM, I’d be happy to send you guys the whole VM, so you’d have it. But so far, it seems bulletproof on VMs. At least I suppose I’ve shown that it is possible that Harry’s machine and my original one are not the only two in the world with this problem. Maybe you will be able to replicate.
Yeah, I thought “network” again. But there’s nothing in really common between Harry’s environment and mine and both fail. Everything in the network where I’m getting failures is also there (and more) when I put a VM on that same network. So that thought exercise didn’t go anywhere.
Hopefully, I’ve at least injected a few new data points into the mix and maybe something will ring a bell with somebody. Hopefully. To tell the truth, I did this so I might be able to just listen to music for a while without having to mess with IT work every time I sat down to listen. But that was not to be, I guess.