In my network, I have some Roon endpoints that are wired, and some that are connected wirelessly. The wired endpoints perform faultlessly, but I frequently have problems with the endpoints using WiFi.
The problems manifest themselves as dropouts, or skipping to the next track partway through playing the current track. This is usually accompanied by the message “Roon: An audio file is loading slowly. This may indicate a performance or hardware problem.”
They occur even with 16 bit 44.1 KHz FLAC files, nothing exotic.
Today, for example, I had two laptops active (both connected by WiFi) both about 5 metres from the WiFi router. One was acting as both a Roon Control and Output endpoint (the Core is Roon Server running on an Intel NUC). The other was downloading a new Windows 10 Insider build from the internet. Since where I live, the internet is a piece of wet string, the download speed is just 4 Mbit/s. However, this was sufficient to cause skipping on practically every track on the laptop with Roon. Once the download had completed, then Roon stabilised, and the skipping stopped in that location.
However, even with a WiFi repeater, dropouts and skipping issues are too common in places in and around the house.
Is this sort of performance hit to be expected, and are there things I can do to improve matters?
The fact that a 4mbit/s download is disrupting 16/44 RAAT playback says something concerning about the performance of the WiFi network or maybe the performance of machine performing the download. There should be miles of headroom between a download at that rate and a disruption of playback.
I make a point to live with WiFi day-to-day, with the goal of making sure our protocols are robust, so I have four WiFi based zones that see frequent use. One, located 30m from the router (ASUS RT-AC66U), routinely holds internet radio streams for 6-8hrs at a time without interruption. Another, a Pi+Roon Bridge with cheap-o Edimax USB<-> WiFi NUB is subjected a fair amount of high-res (up to DSD128) playback.
Something is making all of this fine in my environment, and not fine in yours. I would like for us to get a better handle on these skipping/dropout issues. We get a fair number of reports, and I suspect there might be different root causes for different people. I know that our support team has been focused on researching dropout issues, and trying to work out common threads amongst people reporting the issues.
It’s completely possible that there’s something we could do to make your experience more robust–but it’s very difficult to figure out what that is if we can’t figure out how to experience the problem and debug the issue.
In terms of factors-most-likely-to-help from a gear perspective, a good, modern WiFi router can make a big difference over something built on 5-10 year old assumptions. It’s the first thing I would upgrade if concerned about performance, particularly if the router is still “N”. The jump from “N” to “AC” was the moment in time where (from my perspective), WiFi became a worthy contender for serious use cases.
With regard to the gear, my router and main WiFi access point is a Fritz!Box 7360. Looking at the specs, I see that it is somewhat old-fashioned (Wireless networks compliant with 802.11n (up to 300 Mbit/s gross; 2.4 GHz) and 802.11b/g (up to 150 Mbit/s gross; 2.4 GHz)), so this may be a factor. The firmware installed is the latest available.
The WiFi repeater is a Fritz!Box 1750e. This is a dual band device with better specs than the router. It’s also connected by wired ethernet to the router.
One source of issues may be the fact that sometimes a laptop will switch between the two WLAN access points. If it does this when Roon is playing, the music stops.
I realise that these sort of issues are very tricky to diagnose, but I’ll do what I can to help. Just let me know. Thanks again.
Not sure, as I’ve always avoided them in favour of better Wireless Access Points. One way to know is to throw a large data set at it and see what throughput you get.
One thing I’m trying now is to switch off the WLAN function of the router, and just rely on the WLAN function of the repeater. Since this is an AC device, it may help performance. The laptops also won’t be switching between access points and disrupting playback either.
The question is whether the coverage of the now single access point is going to be sufficient…
@Eric, thanks. Switching off the WLAN access point on the router seems to have helped a lot. I’ve now got just the wired repeater providing (dual band) WLAN access.
I’ve just had four devices (two laptops, a Surface 3 and an Atom tablet) playing simultaneously - two were playing Tidal albums, and two playing 96 KHz 24 bit FLAC files. Three devices were within 5 metres and one wall of the repeater, while one was two rooms away.
I had a couple of glitches on one laptop (a Lenovo Yoga 900s - a Core M7 device). It seemed to be caused by the device switching back and forth between the 2.4 and 5 GHz bands.
It’s early days, but things do seem to be looking up. When Microsoft releases the next Insider Build, I’ll have a chance to see what happens when downloading is thrown into the mix. I’ll report back.
I used to give my 2.4GHz and 5GHz bands the same SSID so devices could freely switch, before finding that that caused (non-Roon-related) problems with some devices. If you have the 2.4 + 5 networks on the same SSID, it might be worth separating them just to see what happens.
@brian - thanks for the suggestion. I shall give that a try.
There was a new Windows Insider Build available, so I was downloading it while using two laptops with Roon, and playing back 96 KHz 24 bit FLAC files. The experience was certainly much better than that described in my first post, but it also wasn’t faultless. I would occasionally get playback stopping, or breaking up, and the “an audio file is loading slowly” message.
I was watching the Task Manager on the Intel NUC (where Roon Server runs), and CPU % for the Roonappliance process would rise from a normal level of about 4% to as much as 50% when these issues occurred.
So still not out of the woods, but things have improved. I’ll carry on trying different scenarios and settings. Thanks.
High CPU usage can cause dropouts if packets aren’t getting out on time. It might be interesting to look at your logs–dropouts do get logged, so we should be able to look and see if anything else in the logs is correlated with the CPU usage.
@Eric, can you help with getting the logs + put them in a ticket for me?
