1.8 - an audio file is loading slowly

Core Machine (Operating system/System info/Roon build number)
Windows 10
Ryzen 7 3700X; X570; 32GB RAM; AMD 6900XT; Ethernet
Roon 1.8 installed on Samsung 980 Pro PCIE4 SSD

Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
pfsense router/firewall (Odroid H2+, Intel Celeron J4115 CPU Quad-core, 8GB DDR4)
Everything on ethernet into Cisco Business CBS110-16T-D Unmanaged Switch
Wireless AP is a Synology Router set to Wireless AP mode (EEE disabled; IGMP enabled)

Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Plugged into the Desktop Core: Schiit Bifrost 2

Two RPi devices running RopieeeXL:
pi2aes (Pi4, ethernet)
Allo Katana (Pi3B, Wifi)

Description Of Issue
Recently performed fresh install of Windows 10 on my desktop where I host Core. I just reinstalled Roon 1.8 and am noticing odd behavior through network endpoints (RopieeeXL).

Playback on the local machine (running core) thru the Bifrost 2 is flawless. Songs load nearly instantly. Roon is installed on C:\ (980 Pro SSD 1TB) and music library (~6k+ files) on a different 980 Pro SSD.

However, playback thru ethernet to pi2aes is slow to load (about 5 seconds for loading a new song or seeking). And, playback thru wifi to the Allo Katana is horrible. I repeatedly see ‘an audio file is loading slowly…’ and it skips to the next song where it repeats the same error.

Thing is, the Spotify Connect functionality works perfectly on both devices. Connects, loads, and responds instantaneously. So, you would think that with my high-end PC and gigabit network, things would load just fine. I don’t expect near-instant load times on the RPi’s, but I don’t see why it would take longer than a second to begin playback.

Ping from my PC to the RPi on Wifi is 1-3ms, and to the RPi on ethernet is <1ms.

I’ve found an example in the logs when this has happened:
3/03 21:43:36 Info:
–[ SignalPath ]---------------------------------------------
SignalPath Quality = Lossless
Source Format=Flac 48000/24/2 BitRate=1693 Quality=Lossless
Raat Device=Allo Katana
Output OutputType=Local_Alsa Quality=Lossless SubType= Model=Allo Katana

03/03 21:43:42 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Ready”}
03/03 21:43:42 Trace: [Katana] [zoneplayer/raat] Endpoint Allo Katana State Changed: Buffering => Ready
03/03 21:43:42 Trace: [Katana] [zoneplayer/raat] wait for ready in 5876ms
03/03 21:43:42 Trace: [Katana] [zoneplayer/raat] Adjusting playback start offset from 50ms to 59ms
03/03 21:43:42 Trace: [Katana] [zoneplayer/raat] Doing ‘ASAP’ Start since we are just playing to one device
03/03 21:43:42 Trace: [Allo Katana] [raatclient] SENT [19]{“request”:“start”,“min_offset”:59916666,“stream_sample”:0}
03/03 21:43:42 Trace: [Katana] [zoneplayer/raat] Endpoint Allo Katana State Changed: Ready => Playing
03/03 21:43:42 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Playing”}
03/03 21:43:42 Trace: [Katana] [Lossless, 24/48 FLAC => 24/48] [100% buf] [PLAYING @ 0:00] G.O.A.T. - Polyphia
03/03 21:43:42 Trace: [Allo Katana] [raatclient] GOT [19] {“status”:“Success”,“time”:131254843281}
03/03 21:43:42 Info: [library] saved recent ProfileId=5efa1bfb-9f72-4c17-a773-e3d4f512ea9d Time=3/4/2021 5:43:43 AM DataType=performer Type=long_nav MetadataId=8236154 ContentId= LibraryId=8236154
03/03 21:43:44 Info: [stats] 5921mb Virtual, 544mb Physical, 139mb Managed, 6380 Handles, 119 Threads
03/03 21:43:47 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:12476}
03/03 21:43:47 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:47 Trace: [Katana] [Lossless, 24/48 FLAC => 24/48] [100% buf] [PLAYING @ 0:05/3:35] G.O.A.T. - Polyphia
03/03 21:43:48 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:48 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:49 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:49 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:50 Trace: [Allo Katana] [raatclient] GOT [18] {“status”:“Dropout”,“samples”:24000}
03/03 21:43:50 Warn: [Katana] [zoneplayer/raat] Too many dropouts (>3s dropped out in the last 30s). Killing stream
03/03 21:43:50 Trace: [Katana] [zoneplayer/raat] too many dropouts. stopping stream
03/03 21:43:50 Warn: [zone Katana] Track Stopped Due to Slow Media
03/03 21:43:50 Info: [audio/env] [zoneplayer → stream] All streams were disposed
03/03 21:43:50 Info: [audio/env] [zoneplayer → stream → endpoint] All streams were disposed
03/03 21:43:50 Trace: [Katana] [zoneplayer/raat] Endpoint Allo Katana State Changed: Playing => Prepared
03/03 21:43:50 Trace: [Allo Katana] [raatclient] SENT [20]{“request”:“end_stream”}
03/03 21:43:50 Debug: [raat/tcpaudiosource] disconnecting
03/03 21:43:50 Warn: [raat/tcpaudiosource] send failed: Object reference not set to an instance of an object.
03/03 21:43:50 Warn: [raat/tcpaudiosource] disconnecting + retrying
03/03 21:43:50 Info: [zone Katana] OnPlayFeedback StoppedEndOfMediaUnnatural
03/03 21:43:50 Debug: [zone Katana] _Advance

Other things I’ve tried:

  • opened UDP 9003 and TCP 9100-9200 ports
  • Disabling Windows Firewall also did not help.
  • recreated the Roon database and let the library analyze all of the tracks
  • adjusting buffer size and other Zone settings
  • restarting all devices – that’s a gimme :stuck_out_tongue:

At first I thought maybe it was something with the Synology router in Wireless AP mode causing an issue, but then I realized that the pi2aes is also suffering poor performance (but not as bad).

The odd part is that prior to this clean install of Windows, I had Roon working just fine with the same setup. This was probably about 2 or so weeks ago.

Hello @Stin,

Looking at this log trace, it’s suggesting that the Allo is struggling to keep up with the incoming audio data. “Dropout” in human terms means “I’m busy doing something else so I can’t process this incoming batch of audio samples right now”.

I’m not aware of anything that changed in Roon 1.8 in the buffering area, so I’d focus your troubleshooting on the network and on the audio endpoint.

A few things to keep in mind:

A) Spotify Connect downloads the audio data via a direct connection from the endpoint to the internet. When you start Spotify Connect playback on a device you’re essentially sending the endpoint a URL for it to start downloading and playing itself. For Roon Ready/RAAT, all audio is first processed by the core and then send to the endpoint via your LAN.

B) There is a huge difference in bandwidth and total throughput with RAAT vs Spotify Connect. Spotify Connect is a 320kbps OGG stream. RAAT sends uncompressed PCM audio samples to endpoints, a 16/44.1kHz stream will come in around 1500kbps.


Thanks. Yeah, I was only noting Spotify because of the lack of latency even with the action of selecting random songs (no pre-buffering a queue). I’m experiencing this behavior even with my old 256 kbps and 320kbps MP3’s. Not that sending a burst of 1500 Kbps should be be stressing anything on my chain of devices.

Given that it’s all within LAN, it shouldn’t be going through my pfsense router at all, but just being routed via my Cisco gigabit switch. Hmm. I’m wondering if there’s something not quite working right with Core on my Windows desktop.

Hello @Stin,

If possible, it may be worthwhile to test with another PC/Mac on your network running Roon in remote mode. Just play to the system output zone and monitor bandwidth/throughput + see if you’re encountering any errors streaming from the Core.


This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.