Intel Core i3-3225 CPU @ 3.30GHz
8GB RAM
wired ethernet
O/S: Windows 10 Pro
(this computer is used as a network-wide 6TB Windows share file server with no programs active other than Roon Server, Jellyfin, and Serviio, all running in the background)
Networking Gear & Setup Details
ISP modem to Untangle router/firewall to Netear unmanaged switch
WiFi via D-Link ceiling AP antenna
Server and endpoint are hard-wired to the Netgear switch
NordVPN is used network-wide running on the firewall
Connected Audio Devices
Raspberry Pi 3B running Ropieee
HifiBerry Digi+ out to Topping E30 DAC via digital coax, out to Sony STRDH190 receiver via RCA
Roon remote on iPad mini gen 5
Number of Tracks in Library
6044 FLAC
19058 MP3
I’m running the above system, and songs always start cutting off partway through after about 20 minutes of listening. Roon will proceed to the next track and continue playing, only for the issue to repeat.
I get the following error on the iPad mini when the track cuts out:
“An audio file is loading slowly. This may indicate a hardware or performance problem.”
This seems to happen on both Tidal tracks and local tracks on the file server.
My network and file server are not obviously struggling and I’m the only user. I’m wondering what to address to fix this problem. Is my i3 server too slow? It’s a pretty old machine, but with a fresh o/s install and everything is hard wired.
OK, then not that If it’s not DSP overload, then the only thing that sticks out in what seems like a neat setup is the VPN. I agree that it’s weird that it first works and then reproducibly stops after 20 minutes. The “loading slowly” message is, however, very typical for either performance/DSP overload or network problems. As nothing else is obvious, I’d try simplifying and would start by trying without VPN. If only to rule it out …
You can also try enabling the local audio outputs on the Windows Core and playing to this. Depending on whether this works or also fails it would also narrow it down in either case
Yes everything works great for the first few minutes, but the audio drop-outs start happening every time like clockwork. Very frustrating. Deactivating the VPN is a good idea. I’ll begin there and report back.
Streaming from Roon directly to the iPad, or to my Mac Mini, does not result in any issues or dropouts. It’s only this Raspberry Pi setup that gives me grief. Unfortunately that’s the main living room stereo.
Ah, that’s a very good point. I would say that this increases the probability that it’s somewhere from the switch downstream to the RPi and beyond. Could be simply a dodgy switch port (try plugging the Pi into another one or the router directly), a dodgy Ethernet cable from switch to RPi (try another one), something in the RPi itself, in the cables/connections from Pi to Berry to DAC (try other ones) or the Berry or DAC themselves.
Is there any way to simplify the path from Pi onward? As far as I can tell, you can’t leave out the Berry and use a different connection to the DAC, right? Maybe borrowing some other streamer with ethernet input and trying that instead of the Pi/Berry/DAC? (If that fails too, it is probably narrowed down to the ethernet; if it works, it puts the finger on Pi/Berry/DAC)
Are you using Toslink from Berry to DAC? Note that the Toslink standard is capped at I think 96 kHz sample rate. Does the issue occur regardless of your source files, including 44.1/16 CD quality?
Very good questions and points. I’m going to put some work into this and see what I can figure out via trial and error. I also have another identical Raspberry Pi in a drawer somewhere that I can swap in to see if it’s that. Thanks very much for the help and direction.
I have exactly the same issue, sometimes even happen earlier in a song. I’m also using Qobuz to stream from and if I use for testing the Qobuz app or the Bluesound app, it plays just fine w7o interruptions (same songs)!!
Tried to analyze that ROON behaviour a bit and my router shows about 5Mbit/sec continuos bandwith use with Qobuz or Bluesound app (96kHz FLAC source) but with ROON there is a much higher peak demand of 80-150Mbit/sec. Guess this might be causing it…
Btw my ROON ROCK on LAN is a powerful i7 with plenty of ressources, so no hardware problem
Roon decodes FLAC files on the Core and sends the raw PCM samples to the endpoint, while most other protocols send the compressed FLAC to the endpoint and the endpoint decodes it. This should account for approx. twice the network bandwidth with Roon compared to other protocols
However, it is not an explanation for 30-60 times larger bandwidth like in your numbers and this is definitely not normal because it is much larger than the raw PCM samples are:
24 bits * 96,000 per second * 2 (stereo) = 4,608,000 bits per second = 4,608 Kbits/s = 4,6 Mbits/s.
Add some RAAT overhead, etc., and you should end up with about 5 Mbit/s with RAAT for 96/24 stereo
I read somewhere here, that ROON tries to prefetch the complete FLAC file and them plays it from memory, which would explain that very high bandwith demand (usually for some 20-30sec only)
I don’t think this is true that it downloads the whole file (there were some measurements somewhere and IIRC it downloads in bursts) but I forgot details. Sure, my numbers were for streaming from the Roon Core to an endpoint, which definitely happens as a continuous PCM stream, not the whole file or large parts of it in bursts. Because this is where @Drew_Robinson’s issue is, i.e., only when streaming from Core to the RPi.
If Drew’s problem were the download from the Internet from streaming services, where downloading a FLAC file (in short burst or the whole file in one burst, whatever it may be) comes into play, then it would affect all endpoints in the same way, including playing to iPad or Mac Mini, but he has no problem with these.
Even then, 5 minutes audio of 96/24 are 1382 MBits (about 172 MBytes), and with 40% size reduction when FLAC-compressed this would be around 830 MBits. If the download happens at 100 MBit/s on average and the whole file was downloaded at once, then it should be done after about 8 seconds. So it is difficult to see how this would cause dropouts after 20 seconds. And a regular 1 GBit/s home LAN should not be affected by 100 MBit/s from router to Roon Core to deliver the FLAC to the Core
I am also seeing a bandwidth spike around the time I was listening to Roon earlier today and experienced the latest audio drops. Keep in mind I was listening to a local file on the server at the time and not a Tidal stream. I’m not sure if this represents a problem or just normal Roon network usage.
Seems to be an aggregate over time with the span from 12pm to 12:10pm probably fitting 10 such bars, so probably 1 bar per minute. So that would be 120 MB over two minutes, which fits approx. a 3.5 minute audio file. If we average that over 2 minutes then this is approx. 8 MBit/s bandwidth, which fits the expectations and should be irrelevant peanuts for a LAN that functions normally. Of course, there is going to be some network load if data is sent over the network
It says essentially what I do regarding the data rates and that the issue in this thread was likely a network issue.
Again, no healthy Ethernet should have any issues whatsoever with Roon’s data rates.
IF there was a bug back then, who knows if it still exists. The vast majority of such issues on the forum are LAN or (more often) wifi problems. Anyway, I have a very similar setup as Drew (router > switch > Core > endpoint, all ethernet) and have not had a single dropout in nearly 3 years of Roon. (Of course Drew has maybe Toslink after that to the DAC, so that could have an effect with high sample rates)
The below image indicates it was a brief event at 12:04, with much lower usage before and after. The audio drop-outs at the time occurred during several subsequent tracks, however, so the effect I experienced wasn’t instantaneous. I don’t know if this spike has anything to do with it.
On which interface, from where to where? Anyway, this is still 1.4 MB/s, so 11 MBit/s, nothing that would make a healthy network drop a sweat. If it has something to do with it, and I can’t rule that out, it would point to the network (or one of its components) not being healthy IMHO
But while listening to a local file, not streaming, like you mentioned before? In this case, Roon (or something else, of course) may well have communicated with the internet at this time, but I don’t see how this could cause the “An audio file is loading slowly” because audio file loading in this case would not go through the WAN interface at all. And 1.4 MB/s is nothing.
Another thing you could try is to set the DNS on the router to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google DNS). Just for giggles and because it is a worthwhile improvement in any case. Lots of weird Roon- or streaming-related network issues discussed on the forum were cleared by avoiding a crappy ISP-provided DNS, even if the connection between these things was not obvious.
If it’s not DSP overload, then the only thing that sticks out in what seems like a neat setup is the VPN. I agree that it’s weird that it first works and then reproducibly stops after 20 minutes. The “loading slowly” message is, however, very typical for either performance/DSP overload or network problems. As nothing else is obvious, I’d try simplifying and would start by trying without VPN. If only to rule it out …
