@support I am currently under the trial period and have been experiencing random audio drop-outs with both Roon 1.2 and 1.3 to a macOS Client. They occur when listening to local ALAC files or Tidal albums.
The Core is running under macOS Server 10.12.3 on a Mac mini Core i5, 4GB RAM, 240GB SSD. The Client is running under macOS 10.12.3 on a MacBook Pro 13" Late 2016, 16GB RAM, 512GB SSD.
Our WiFi network is in perfect shape (no latency or packet loss). Listening to the same tracks via the Tidal app works as expected.
Hi @Pascal ---- Thank you for the report and my sincere apologies for the wait here. Our knowledge base has very good documentation on what can cause dropouts to occur and the best approach to troubleshooting them. That article can be found here, may I ask you to give it a read and let me know what you have tried thus far.
Furthermore, can you please provide me with the details of your network configuration/topology as well as providing insight into any networking hardware you may be implementing. I want to have a clear understanding of how your device are communicating and what tools are being used to make those connections possible.
Let me look at the document and come back to you with a network topology explanation. I have been using Plex for many years without any dropouts and can confirm that there is no packet loss. Plex is running on the same Mac mini server hardware.
I am starting to suspect the macOS Core build as I am experiencing dropouts with local files, Tidal as well as Internet Radio streams. The dropouts occur to a macOS Client, a NAD D7050 via AirPlay and even to a Bluesound POWERNODE 2.
Tidal drops out via Roon but the same album plays fine via the Tidal app.
You can delete my two other posts regarding dropouts via AirPlay and Bluesound as it might be simpler to track down the issue and discuss via a single thread.
By the way it appears RoonServer is spewing a lot of errors and trying to connect to a Roon Labs Push Server:
03/01 20:29:09 Warn: Error in web request https://push.roonlabs.com/push/1/connect: NetworkError (The remote server returned an error: (502) Bad Gateway.)
03/01 20:29:09 Trace: [push] request to manager failed
03/01 20:29:09 Trace: [push] retrying connection in 3292924ms
Hi @Pascal ---- Thank you for touching base with me. I have consolidated your posts to this single thread in the interest of keeping all of this information together.
RoonServer has been stable within both a macOS 10.12.3 and Windows 10 Virtual Machine environments running on my MacBook Pro.
The WiFi interface was enabled by default but not joined to any WiFi network. This appeared to trigger airportd to waste CPU cycles. The symptom stopped once I disabled the WiFi interface. This seems to have reduced audio drop outs under 1.3 build 208.
@support However streaming performance now seems to have been corrected under 1.3 build 209. I no longer experience drop outs to macOS or Bluesound clients since the update. Did you optimize anything under the hood ?
Hey @Pascal – while I can’t really comment too much on Bluesound’s streaming protocol, I can tell you that we know many many people are using Roon over WiFi, as was mentioned here.
Can you tell us a little bit more about your network, topology, and hardware? Are you using 802.11ac?
Is it me or the RAAT protocol hasn’t been designed to work via 802.11n WiFi ?
Bluesound is only equipped with 802.11n unfortunately.
Network topology:
AirPort Extreme (Living Room) -> HP Gigabit Switch (Living Room) <-> HP Gigabit Switch (Studio) <- AirPort Express (Studio)
A Mac mini RoonServer sits on the Gigabit Switch (Studio)
A Bluesound POWERNODE 2 now sits on the Gigabit Switch (Living Room)
MacBook Pro(s) and iPhone(s) connect via 802.11ac in the living room and via 802.11n in the Studio
Playback to the Mac is more stable since build 209 has been released.
AirPlay via Roon and Bluesound via the BluOS protocol work as intended over WiFi.
I am able to listen without any drop outs to the POWERNODE only when connecting via Gigabit Ethernet. It is so bad via WiFi that sending a RAAT audio stream via 802.11n WiFi to a Bluesound device seems to flood and freeze either the WiFi interface or BluOS entirely for a couple of seconds (the device stops responding).
We have lots of people running 802.11n as well, but wifi can be hugely variable and we’ve seen all sorts of issues resolved by moving the router a few feet over, by switching to a different channel, by upgrading to a different router, etc. Under some conditions Airport Extremes have been ok, and in other configurations they’ve been pretty bad.
Yeah, I get it, this sounds frustrating We are not hearing widespread reports, so my sense is still that this is something environmental. Have you tried running the Powernode right next to the router? Is there another router (or channel) you can try? The only real way forward here is isolate the problem and figure out why you’re seeing different results from others.
Let me know what you’re trying and how its going, and I’m sure we can get this working @Pascal. Thanks!
@mike I understand network configurations can vary from user to user but I can guarantee you this is not an environmental issue since:
I am not experiencing any packet drops
Ping latencies are good
Roon can stream 16-bit audio via AirPlay to an Apple TV 4 (802.11ac 5Ghz)
BluOS can stream MQA 24-bit audio without any drop outs to a Bluesound POWERNODE 2 (802.11n 2.4Ghz)
Plex can stream HD 1080p video files without any drop outs to an Apple TV 4 (802.11ac 5Ghz)
NetFlix can stream 4K HDR video files without any drop outs to a Sony Bravia 4K TV (802.11ac 5Ghz)
Only Roon has problems streaming via WiFi. What I believe is happening is the RAAT protocol not being able to cope with a 802.11n device. I have been streaming perfectly via Gigabit Ethernet since last week. This unfortunately rules out the rest of the Bluesound product line.
I have opened up a support request with Bluesound and would need some help investigating the current symptoms.
Roon is able to flood BluOS and either kill the WiFi interface, the RAAT process or freeze the OS stack entirely. Audio will start dropping out, the device will then disappear from the Audio Zones list and reappear a couple of seconds / minutes later.
I have since moved on from the Bluesound POWERNODE 2 to a NAD C 368 with MDC DD-BluOS module.
I can confirm Roon is not able to stream music efficiently via 802.11n WiFi and triggers Bluesound players to disappear from the network. This is not the case when using the BluOS protocol.
I have read your blog post about WiFi performance and router recommendations. Even though the Roon team does not seem to recommend Apple routers for some reason, I am convinced this performance issue is tied specifically to 802.11n.
Unfortunately this excludes any and all Bluesound models and most probably all other Linux-based embedded platforms when using certain types of routers.
I have no tolerance for tacky industrial design and will eventually be moving on to a Mesh-based router platform. It would be interesting to read which routers have been certified in your lab for both 802.11n and 802.11ac streaming.
Hi @Pascal ----- Thank you for touching base with me and sharing your feedback. Both are appreciated. My apologies for the wait here.
As Mike had mentioned in his response, we do have many users working fine with 802.11n and Apple products as well. Now obviously this experience can vary due to such things as environmental factors and the amount of traffic on a given network.We are always working to improve Roon’s performance, although we do recommend using 802.11ac when possible.
I also see from your post that you have plans to move to a Mesh-based network configuration. We heard positive reports about Eero or Orbi, although they are not yet part of our QA process. Please let us know what the experience is like with the new setup in place as your feedback is valued.
We are not hearing widespread reports, so my sense is still that this is something environmental. Have you tried running the Powernode right next to the router? Is there another router (or channel) you can try? The only real way forward here is isolate the problem and figure out why you’re seeing different results from others.