Roon Core Machine
Asus mini MrChromebox-4.18.1
description: Asus Mini i7 16GiB RAM 128GiB SSD
serial: J4MSCX004067
*-firmware
description: BIOS version: MrChromebox-4.18.1
*-cpu
product: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
*-memory
description: System Memory
physical id: 9
slot: System board or motherboard
size: 16GiB
*-bank:0
description: SODIMM DDR3 Synchronous 1600 MHz (0.6 ns)
product: ASU16D3LS1K1DGR/8G
vendor: Kingston
*-bank:1
description: SODIMM DDR3 Synchronous 1600 MHz (0.6 ns)
product: ASU16D3LS1K1DGR/8G
vendor: Kingston
*-scsi
physical id: d
logical name: scsi0
capabilities: emulated
*-disk
description: ATA Disk
product: M.2 SSD 128GB
logical name: /dev/sda
size: 119GiB (128GB)
capabilities: gpt-1.00 partitioned partitioned:gpt
configuration: ansiversion=5 guid=e255dfee-7232-4d05-b563-38165a4fe09d logicalsectorsize=512 sectorsize=512
*-volume:0
description: Windows FAT volume
vendor: mkfs.fat
size: 1073MiB
capabilities: boot fat initialized
*-volume:1
description: EXT4 volume
vendor: Linux
size: 2GiB
capabilities: journaled extended_attributes large_files huge_files dir_nlink recover 64bit extents ext4 ext2 initialized
configuration: created=2023-01-14 01:23:37 filesystem=ext4 lastmountpoint=/boot modified=2023-02-22 23:28:36 mount.fstype=ext4 mount.options=rw,relatime mounted=2023-02-22 23:28:36 state=mounted
*-volume:2
description: EFI partition
logical name: /dev/sda3
size: 116GiB
capabilities: lvm2
Networking Gear & Setup Details
Wired, no VPN, Asus RT-AX92U router. 1GiB fiberglass internet:
Speedtest by Ookla
Server: WorldStream B.V. - Naaldwijk (id: 6554)
ISP: CAIW Internet
Idle Latency: 4.25 ms (jitter: 0.07ms, low: 4.17ms, high: 4.29ms)
Download: 938.57 Mbps (data used: 446.1 MB)
9.37 ms (jitter: 0.57ms, low: 4.48ms, high: 10.58ms)
Upload: 927.44 Mbps (data used: 441.3 MB)
4.49 ms (jitter: 0.22ms, low: 4.07ms, high: 5.14ms)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/51e6a662-6110-48b6-acaf-ad7ee31b0401
Adapters on board of Roon core:
*-network
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
logical name: enp1s0
*-network
description: Wireless interface
product: Wireless 7260
vendor: Intel Corporation
physical id: 0
logical name: wlp2s0
Connected Audio Devices
*-pci
*-usb
*-usbhost:0
product: xHCI Host Controller
vendor: Linux 5.4.0-139-generic xhci-hcd
configuration: driver=hub slots=11 speed=480Mbit/s
*-usb:1
description: Generic USB device
product: EDIROL UA-25
vendor: Roland
physical id: 5
bus info: usb@1:5
version: 1.07
capabilities: usb-1.10
configuration: driver=snd-usb-audio maxpower=480mA speed=12Mbit/s
*-usb:2
description: Audio device
product: DX3 Pro+
vendor: Topping
physical id: 6
bus info: usb@1:6
version: 1.25
capabilities: usb-2.00 audio-control
configuration: driver=snd-usb-audio speed=480Mbit/s
Number of Tracks in Library
12k tracks
Description of Issue
I’ve experienced slow track switching often. I already spotted that if starting
a new track takes long (>30s) there will be a period of high CPU usage on the
Roon core at that time.
Today, after some time of reduced listening, the experience was much worse than
usual, to the point where things were unusable. Over a period of many hours I
got a consistent pattern of 2-minute drop-out every ~10 minutes. During such a
drop out the music stops, no audio devices show in the app and the app is
barely functional. The core is still available though (which the UI reflects).
Any attempt at remediation on the UI side (restarting remotes or using a
different device) had no effect.
I shifted my observations to my Roon Server install. Below are several screen
casts of adjacent problem episodes. I show the Roon Remote UI alongside system
monitoring (later episodes showing more relevant detail).
All music were Qobuz tracks from outside the library. Audio format&resolution,
streaming paths and so on are recorded as part of the UI.
first episode
- 01:48:41 - start heavy CPU on Roon server
- 01:48:52 - music drop out / “crash” in the apps
- 01:50:41 - recovery, apps respond again
second episode
screencast, the first 2-minute drop-out is still in view in the graph histories
- 02:03:41 - start heavy CPU on Roon server
- 02:03:52 - music drop out / “crash” in the apps
note at 02:05:10 I started to include memory, disk and process list stats
- 02:05:41 - recovery, apps respond again
third episode
screencast, along the way we can see a change of album format and corresponding
bandwidth usage
- 02:18:41 - start heavy CPU on Roon server
- 02:18:53 - music drop out / “crash” in the apps
along the way I decided to drop disk cache (block/dentry caches, which is
seen to free up 1.8GiB of “Cached” memory) - 02:20:44 - recovery, apps respond again
fourth episode
screencast, I finally get the sense to show the actual LAN nic instead of the
loopback network (localhost), also seen the Wlan which is clearly not used
- 02:33:41 - start heavy CPU on Roon server
- 02:33:52 - music drop out / “crash” in the apps
- 02:35:43 - recovery, apps respond again
Bonus: restarting the Roon service. Also shows home screen (for library stats?)
screencast, note that after the restart the memory usage is negligable compared to
before, but the apps already work as expected
After the restart, none of the issues occurred for the time it took to write this report, which is roughly an hour. At the time I conclude this remark, the memory usage is still way down compared to the state in which the problem was manifesting.
Besides, it is notable that the overall CPU usage is way lower, compare:
My hunch is that the .NET code leaks resources (perhaps a native interface that
doesn’t free all native resources under an IDisposable interface?). After some
while the garbage-collector is gradually stressed more and more, raising CPU
usage and eventually leading to very noticeable stop-the-world cycles.