I’m running Roon Rock on an Intel 8i5. The Rock is connected over WiFi to my router and then all of my endpoints use the same mesh network. I have a mix of Bluesound Pulse, Minidsp SHD, and HiFiBerry endpoints. I am running a Ubiquiti AmplifiHD mesh that allows me to monitor download speeds in real time. My internet download speeds are on the order of 200 Mbps. On many occasions when I have multiple zones activated, the music cuts out randomly, especially at the beginning of a new album. This seems highly correlated to Roon pull very high bandwidths - often on the order of 125 Mbps - at the very beginning of a track. Because my Rock unit is connected to the router via WiFi, it seems like the endpoints are being starved for bandwidth. I question why Roon needs to download so much of a track/album rather than a more modest amount of bandwidth throughout the track. Has anyone noticed this? Would it be possible to cap the bandwidth pull so that the rest of my WiFi network is not cut off?
Hi @Michael_Decelle,
I moved your post over to the #roon:feature-requests for Roon to consider…
However, I highly recommend hardwiring the Roon Core to your LAN … as real world bandwidth availability and contention are still significant issues even with modern mesh architectures.
Hi All,
Thanks for the quick responses. I should further note that local streaming of my library from my NUC to my endpoints works just fine (I have a NUC-resident hard drive with my FLAC files). I understand that a wired connection is best and I would obviously do that if it were possible, but it is not. I also note the I can stream with no cutouts high-resolution files from TIDAL when I am running my Logitech Slimserver so the issue seems unique to Roon. Slimserver seems to pull files at a more constant and reasonable rate where Roon seems to jam it all down within the first few seconds of a new track. When playing a full album, it seems to try to pull the whole album at once. This seems unnecessary.
Thank you!
I think your observation is correct.
I have my Roon core on a custom built headless media PC running Ubuntu 18.04, and to remotely administer the system I recently installed on the server the package Cockpit which on its main screen displays running graphs of CPU and memory usage, disk i/o and network traffic. I observe how at the beginning of every track there is a network traffic peak of about 80 Mbps and Disk I/O peak of about 32-48 MB/s. This is streaming Tidal High Resolution. Roon seems to download and buffer the entire track.
My Roon core is WiFi-connected, and in spite of the network traffic peak I haven’t experienced dropouts. Here at my place this is working well, but I understand that this might be the reason why Roon very much recommends to connect your core device via Ethernet.
Can’t argue with your stats, but in the case of streaming, I don’t believe Roon downloads/buffers the entire track.
If it did, then the scrub bar wouldn’t be a flat line, but would display as it does with local music.
If it weren’t so, I’d expect to see some traffic while a track is reproducing, and I don’t. There only is traffic for a second or two shortly before a new track starts. I think there is a ‘flat line’ simply because Roon doesn’t seem to do on-the-fly audio analysis of downloaded streamed tracks.
That’s hard to believe.
So your Roon Core doesn’t need to be placed near any of your endpoints.
You’re free to place your Roon Core anywhere you can connect by wire to your main router. Add a unmanaged switch if all of the routers Ethernet ports are already occupied.
It does not, at least not with Qobuz. Watch the logs as its playing. It will request each track shortly before the current track ends (so it can do gapless playback). You are correct that it will download and cache each track basically as fast as the network can provide it, though. So you do get small network bursts at the start of each track.
That said, assuming you aren’t doing any upsampling, I wouldn’t expect this to cause problems on your Wi-Fi network with playback. 44.1k/32-bit is only about 3mbit from Core to endpoint. And Roon also pre-buffers about five seconds to the endpoint (assuming RAAT protocol). So dropouts mean you are losing a LOT of data on the Wi-Fi network. Someting else is broken.
That’s a programming choice at this stage. Plex, for example, has displayed streaming track waveform on the scrub bar for some time.
Doing so would be fixing a symptom of a problem not the problem itself. Your wifi is not up to snuff to handle the multiple streams.
Before you give up on anything, make sure your wifi is optimized for your RF environment. If you have an Android phone or tablet, download Ubiquity WIFIMan. Use it to analyze your environment and optimize it. Channel and power both matter. Often lower power can perform better than 100% which also amplifies more noise…worth a try.
Roon does download the entire track in a burst which is good as then the network and the interrupts generated to service the NIC can cease and the computer can be ‘quiet’ again.
Moving your Nucleus closer to any of your access points will help or moving an access point closer to the Nucleus does the same thing.
Thanks, Andreas, for your confirming analysis. I will leave it to the Roon developers to decide whether this is the right way to engineer traffic flows. My WiFi network works just fine in every other personal use case. Having sheltered in place now for a few months with my family all running simultaneous Zoom sessions over this network, without dropouts and while also streaming various other services like Netflix, I’m pretty confident that I have a well-configured network with -52 to -56 dBm signal strength at all of my mesh points. What it cannot seem to handle is 120Mbps incoming data bursts while wirelessly distributing this same audio to three or four different endpoints across multiple hops. Internal streaming from my music library is fine, Tidal streamed from my NAS-based Squeezebox server to all of these same endpoints is fine. Even Roon works if the download peak stays below 50Mbps or so. And this is just with 44.1kHz/16-bit files, not high-res. I don’t understand the perspective that reducing the download bandwidth would be fixing the symptom not the problem. It seems like good traffic engineering should not allow a 3-4 Mbps steady state stream to be compressed into a 4-second, 120 Mpbs burst for no compelling reason.
What puzzles me is the fact that there are, at times, the infamous moments when a track stops midway and the message appears to the effect that ‘Tidal is loading slowly’ and that there must be a network problem. If Roon downloads and buffers an entire track before starting reproduction, while still reproducing the last seconds of the track before, how could that be? I suspect there are other, more low-level, networking problems with Roon. Or with Tidal, or both.
I get this as well with Qobuz and used to get it while I was with Tidal. Do we have any understanding of the throughput that Roon needs for a given resolution?
I don’t know if my question is irrelevant or otherwise nonsensical, as I am not a networking expert. However, when I do have issues I notice that 16/44 files don’t appear to be the issue, but rather 24/48 and above.
So, I was thinking if Roon needs at least X Mbps, then so long as we ensure that our ISP and Wi-Fi router is achieving that, we should be good.
Because its having network problems between your core and the endpoint. These show in the Roon Server logs…
Well, no. My DAC is connected by I2S to my core, so the core is also the endpoint. To me it has happened several times that while happily listening to a track, the music suddenly stops and after a second or two, skips to the next track (while streaming from Tidal). And I believe I am not the only one experiencing this. So, if the track has been downloaded and buffered on the core device, why would the reproduction stop in midst of a track and skipping to the next one? There must be other (communication?) things be going on between Roon and Tidal, and there happen to be sometimes problems, which could be attributable as well to Tidal as to Roon - I don’t know.
Spending lately way too much time on this forum reading through a lot of support requests by new and not so new users, I very distinctly get the impression that quite a lot of the problems users experience with Roon are network-related. And many users seem to not experience problems with their networks but by using Roon. And while there might be at some times obvious misconfigurations, this is not always the case. These problems are serious enough to alienate users from Roon, to put them off. I think Roon should put more attention to this, maybe integrate into its software suite some basic diagnostic function to check network functionality during installation and use of the software. That is just an idea to eventually make it easier and more evident for users if there are problems with their networks which will impact the correct operation of Roon. I can fully understand why users might get frustrated with Roon.
That said, I for myself have not had problems more serious than the mentioned occasional hiccup while streaming from Tidal. And I keep my core connected by WiFi, and a second endpoint, as well. But I also monitor my signal strength and feel comfortable making changes to the WiFi radio on the router.
I can say that I have a similar issue as to what you describe using Qobuz. Interestingly, if I stream directly from the Qobuz app, there are no music interruptions or other issues.
I believe there is some hidden problem with regard to the way Tidal/Qobuz are being integrated into Roon. And I also think that far too often the blame is simply put on the user’s network, when the same user - like you and me - doesn’t experience network problems while streaming with the Tidal or Qobuz app. And I understand that folks might feel frustrated by this.
I don’t have Tidal, so can only comment on what I see in the Roon logs when using Qobuz. When it starts playing a track, you get a few messages about it starting to cache from the Qobuz streaming endpoint, and then a short time later, a message that it has completed caching. Watching the TCP sessions on the Core (I run mine on a CentOS 7 system so I can log in and look at the system, logs, etc instead of the locked-down “appliance” that is ROCK) is also consistent with this. Using ‘iftop’, it’s really easy to see the connection to Qobuz doing bulk download at the start of the track, and then by ~30 seconds in, the traffic from Qobuz stops entirely (these are ~7-10 minute long songs). (Also, bonus to Qobuz for supporting IPv6!) In my case, my Core is connected via wired Ethernet and my Internet service is ~300Mbit/s down. Most of the music genres I listen to are only available in 44.1/16, so pretty easy to cache in entirety in the short times seen in the log entries.
After that, it’s all just the Core streaming to the endpoints, which, with one exception, are also all wired Ethernet in my case. Wanna guess what the only endpoint I experience Roon dropouts on is? 
(And I don’t even blame Roon – the device in question only supports 2.4GHz and I live in a dense urban environment where over 60% of the 2.4GHz duty cycle is consumed by beacon frames alone. That’s not even any data getting transferred, just all my neighbor’s access points shouting out “I’m here!”… So 2.4GHz is mostly unusable for ANY Wi-Fi device where I live.)