Yet another option that has worked well for me…
I have a Netgear Orbi mesh WiFi setup which worked well most of the time, but did have occasional pauses. An old Mac Pro laptop is used exclusively as the Roon server. Sonos speakers are connected via WiFi.
Adding a Thunderbolt to Ethernet adapter, to connect the laptop to an Ethernet port on the Orbi satellite, appears to have made the pauses disappear.
I see we finally come to a conclusion that is somewhat known but explained by rather little official information from roon.
roon implementations sometimes demand a lot more from a particular technical component than other more common systems/applications do.
If asked, roon will openly admit that they implement visions which need quite modern infrastructure. And they clearly say that you are simply out in case you don’t own it or you don’t know how to handle it.
The problem is there’s rather little concrete official information regarding specific demands in particular use cases. Network is just one part of it.
I know plain PCM stereo listening is by far the most common use case. But there are lots of options regarding DSD and even multichannel. And these demand e.g. more performance from a roon endpoint or roon server. Esp. in case you want to use realtime conversion or even DSP.
Now, roon officially recommend different supported NUCs. And I couldn’t find any official information on how far these different models support a concrete PCM/DSDx/stereo/multichannel/conversion/DSP combination regarding sufficient performance. I believe this kind of information would be of great help.
And what about the concrete RAAT network demands for the different PCM/DSD/#channels combinations?
As a (potential) customer I’d demand for a rather simple compatibility/recommendation matrix. Could help when making decisions. It’s not available.
The most concrete recommendation regarding e.g. the disk type to use for roon’s own database is to avoid HDD spindles under every circumstance.
Also, stating that for ethernet connection you should definitely enable flow-control if you use a managed switch and want to listen to beyond PCM stereo was extremely helpful for me.
But as you can read in the pretty long best practice page you need to know and to understand quite a lot to finally build a properly working roon environment. The roon products themselves pretend to be quite simple but regarding the technology and the effort to get them run properly, at least in some cases, is not.
I often asked myself what would I’ve done if I was not an IT professional… So, to close here, roon as a company and as a set of technologies demand quite a lot from their customers. And if a customer is not able to understand and follow all the technical advices (if available), he/she will be simply out, IMHO.
Some of the items you list are straightforward. Avoiding mechanical hard disks for the Roon database for example, although, as has been pointed out in another thread, even that can be nuanced when, for example, the disk is not being actively used for anything else and the size of the disk cache is sufficient to hold the database (unlikely except in large RAID arrays) or the significant part of it.
I think that explaining what NUC or other computer is required to support DSP operations is a very difficult thing to do because of the huge number of different DSP configurations and different computer specifications that can be used with Roon (even assuming that the OS ifself makes minimal difference which is broadly, but not always, true if the computer is not being used for anything else).
They could give some example setups, but I don’t think that that would necessarily help for two reasons:
The nearest that they come for recommendations for DSP performance are at:
This doesn’t say much - but it does point out that heavy DSP needs powerful processors.
In the area of networking, Roon definitely does make heavier demands upon a system is networking except when streaming local library content from Roon Server local storage. However, it is not difficult to understand why, and thus, just by thinking about things analytically, to identify where weaknesses in your network may lie.
If you thing about it, a normal streamer using something like Tidal Connect only uses the local network in one direction (ignoring the almost insignificant TCP acknowledge traffing in the reverse direction).
i.e Router → Streamer
However, with Roon, assuming we have a separate streamer (or audio endpoint), the situation is different. Now, streaming from Tidal looks like:
Router → Roon Server, Roon Server → Streamer
This difference does not matter too much on wired networks - because traffic in one direction on a wired link does not share bandwidth with traffic in the other direction (full duplex) and traffic on one ethernet link does not share bandwidth with traffic on a different link (modern ethernet is a switched packet system).
However, it matters much more with WiFi (And Ethernet over Power [EoP] systems) because all traffic between all WiFi (or EoP) connected devices (in both directions) contends for the same WiFi (or EoP) data bandwidth and further, if there are any devices that have a weak signal, they will be negotiating a lower data rate which means that, proportionately speaking, they will be using ‘more than their fair share’ of the available WiFi bandwidth.
I have a single WiFI 6 TP link router covering my small home. I have not yet suffered any drop outs from Room stream to up to 3 devices. I have used RAAT with a HiFiBerryOS Pi. I have used AirPlay 16/44 with HomePods and I have used squeeze box protocol with Denon HEOS with the RHEOS extension. The highest bitrate I have streamed is Peter Gabriel’s i/o in 24/96. Because Roo n can send FLAC conpression the bitrate is going to be about 1/2 the raw bitrate of the stream. The source is a NUC Roon core wired to my router but my endpoints are all wireless. Occasionally I can get loss of sync but never stops or gaps.
The thing with WiFI is that only one device at a time can transmit on each frequency/channel - unlike Ethernet. And that also includes other routers on the same WiFi channel such as a neighbour. Each device has to wait for a pause in the network to be able to transmit. So if you live in an area with no neighbouring devices and a wired source and single WiFI endpoint then you will probably be fine. Once you start to get mesh networking involved or multiple endpoints in a congested environment like an apartment building it’s going to get rough even if the raw throughput of your 802.11ax router should be more than enough for even the highest bitrate. This is especially true if you have to deliver packets in realtime with limited buffering. And stay in sync with other devices. A single stream of heavily buffered video from the router to a single TV is actually much simpler to do even if the bitrate is actually much higher.
All that said I have had no less success auth RAAT than any other streaming protocol (And I have used AirPlay, chromecast, HEOS, Sonos, Squeezebox)
WiFi can work very well - provided that there is plenty of available data capacity.
If you start increasing the number of endpoints and increasing the sample rate and/or bit depth used on each of those endpoints, then WiFi will break down before a wired network.
Also, if the network gets used for any other network heavy activity at the same time as Roon, then WiFi will break down before a wired network.
Yes, all fine but roon could provide some more detailed information on which situations are rather critical and which are fine 
. I mean, I guess they already know them from testing, don’t they? And you can hardly make concrete decisions on rather vague information. We spend quite a lot of our money and time here 
In case certain wireless use cases would e.g. require Wi-Fi 1,2,3,4,5,6 they should simply tell us 
And, from my very own experience, the “real fun” starts with DSD multichannel…
It’s just a bigger lack of information roon show us when it comes to initial decisions for building a running system.
I learned by pain
In fact they tell us to use an ethernet connection for the computer hosting the Roon core. That tells us all we need to know - if we want it to work as the company designed it, use an ethernet connection, and don’t be surprised if you run into problems if you use wi-fi.
Roon can’t predict the level of wi-fi needed for your system to function correctly. Wi-fi performance depends on way too many factors, e.g.
Device distance/signal strength from the nearest AP to the device (this significantly affects bandwidth)
The number of devices connected to the AP and their data load.
The radio environment - how many of your neighbours’ wi-fi networks are crowding your broadcast channels.
Since the last 2 or three updates the overall stability of ROON RAAT for me has significantly decreased. Music just stops playing.
I never had issues. All mir Clients are hard wired. No Wifi.
The only problem I hab before was that internet radio stations stopped. Sometimes.
But now my own music stops. Tidal streaming stops after a few minutes.
I haven’t changed anything in my network.
But this is so annoying. While writing this text the music on my KEF LS50WII just stopped. My wife is really annoyed. And that’s a stopper…
Of course it is, but so is complaining about an issue with Roon without raising a support request first.
Where do you know that I have not done? I gave feedback at the survey and am liking at the issue lokally, at first.
But right now everything points at the updates‘d roon versions
Everyone’s posting activity/history is viewable. No support post has been raised by you recently in the forum as far as I can see.
Ok. So I found the issue. For me it was a ram thing. The 32gb I have in my server were used.
That was the reason why restating Roon fixed it. The last time Roon used 6+gb.
So made an upgrade and so far no issues.
It is a problem with RAM memory. Increasing the RAM is part of the fix. However it will still blow out from time to time for no apparent reason. You still will need to restart ROON from time to time.
So this is a known issue?
Let’s see how long it takes to get instable. Upgraded from 32gb to 128gb. So there is plenty of free ram.
My virtual machines also got virtually upgraded.
So I think I should be safe for some time.
But will restart Roon when I see that the task is running too long.
A little Skript should be able to handle that
I started this thread after being plagued by all sorts of problems and even paying to upgrade to ethernet throughout the house, as we were told that drop outs were due to poor local networks. I was still being plagued by drop outs even after the upgrade. It was by chance that I noticed, using task manager, that my RAM usage was off the wall. Some investigation around this site indicated that the real problem might be what I call “memory leaks” and there are few threads and posting on this issue.
I upgraded to 16 Gb of RAM (I have a relatively old PC that cannot be upgraded to Windows 11 - so will be looking to replace in the next year or so). This proved to be remarkably inexpensive fix done by a computer shop.
This has improved stability considerably, but not totally eliminated the problem. However, I now know the solution, if I am having lots of drop outs or “stutterings”, it is time to do a Roon restart. This takes me only a few minutes.
I have no idea what causes this as I am no tech expert. However, at one stage in my career, long, long time ago in a galaxy far away, I was a User Data Base Adminstrator working on a large mainframe. Our motto then was that “space is the final frontier”. It seems that at least for this application on windows PC, that this remains the case!