It is very evident that Roon RAAT is less stable (ie subject to more frequent dropouts) than either Chromecast or Airplay. (I know I should be using Ethernet cables, but that is not always practical and I can happily stream Ultra High Defintion movies over my wifi without dropouts. This should also be possible with an audio only stream).
I am sure that there are technical reasons for this but as a customer (and non technical person), I have not much interest in these reasons.
I am hoping that, at some stage, development resources could be expended in making streaming using Roon RAAT more robust and less prone to drop outs.
I thought I’d share these two links before I give my 2 cents worth.
I have had equal success with Google WiFi (1st gen) nodes x 3 and my current Unifi WiFi network with 3 access points using RAAT.
You don’t mention your network equipment and setup. Could be helpful if you do so we can understand your viewpoint.
As popular as mesh networks are they can cause more dropouts using Roon if they’re transmitting between each node using WiFi rather than ethernet.
Roon RAAT is a heavy beast compared to UPnP, Chromecast, Airplay etc.
I have used most protocols with varying outcomes. Airplay is good, but sync issues for multi zones can be an issue within Roon. Chromecast is also good but don’t have extensive use knowledge. Both these are limited in terms of bit/sample rates compared to RAAT.
As @Michael_Harris (sorry ) told me once, if you can stream DSD 256 on your WiFi network, then you’ve got a solid WiFi network, or words to that effect. I have one access point limited to 100mb bandwidth due to a cable issue. I can stream to one endpoint in DSD256, whilst 16/44.1 to 2 other endpoints from the same AP.
It’s way to easy to blast networks for being the cause for issues, but a robust network I feel is still required.
Comparing HD or UHD video content to Roon RAAT based on success of WiFi use are two different beasts. Others here are way more technical than I, I’m just a user with above the norm knowledge.
Buffering for video works in a very a different way to streaming audio and indeed RAAT which requires minimum latency to maintain the high level sync it’s capable of. You can’t compare them at all really. Airplay is only capable of 44.1/16 and it’s ALAC which is compressed compared to RAAT which is uncompressed PCM and much larger file size.
WiFi can work perfectly fine for RAAT does for me without any issues. But i don’t rely on any mesh have dedicated aps that are hard wired back to the router and make sure i have enough aps to provide ample coverage so not one ap is overloaded.
Unfortunately there’s a lot of marketing hype around mesh networks. Wireless mesh networks are limited by the wired connection to the primary node and the signal strength from that to the wireless nodes. Every AP added reduces overall bandwidth.
A proper setup uses wired backhaul to each AP. Every AP added increases overall bandwidth.
Somehow I was tagged in this for a humourous past quote . I stand by that quote (because it helps stress test a WiFi connection for audio playback) and also agree with what @Simon_Arnold3 and @Graeme_Finlayson said.
You are not comparing like with like and there is a huge difference between the requirements of AirPlay/Chromecast/RAAT and the requirements for those delivery mechanisms. If Airplay and Chromecast work’s (because they have lower bandwidth protocol) just use them and be happy.
But also be aware that you are not following the best practices for Roon or RAAT at that point.
Personally I now use an Orbi Mesh network with dedicated back haul with most of my devices themselves connected via Ethernet and hence my testing of the DSD256 music to make sure that anything that is using WiFI has way more bandwidth than is ever going to be needed for any normal playback and therefore never had any drop outs.
I have Roon via a mixture of RAAT, Airplay, and Chromecast – all wifi.
I’ve come to the same conclusion: it all works best with far stronger wifi connections than needed. This meant a lot of experiments with equipment and placement.
100% agree with that.
Not all WiFi devices are created equal and there is a huge difference in performance, which requires testing to find the perfect settings for each device.
I don’t use AirPlay but I do use RAAT, Chromecast and Squeezebox as well as Sonos and I reduce my Sonos to 16/44.1 for completely reliable payback.
The WIIM Pro plus is happy streaming over Chromecast and Squeezebox all day at 24/96 without ever dropping a beat.
My Chromecast Audio pucks are not capable of that so I was playing them at a lower bit rate (before replacing with WIIM).
Then don’t use RAAT. The things that make RAAT preferred like bit perfect, DAC sync, volume sync, multi zone sync, etc. are the reasons it’s “unstable”. The answer is your network. Fix your network to support RAAT if you want to use RAAT. Otherwise use one of the other ones that work
Could it be better? Sure, I don’t agree with all the design decisions Roon made. But I can’t argue it sounds good and works very well given low enough propagation delay, bandwidth, and all the other things that make a “good” network.
An interesting set of responses! Thank you for taking the trouble to respond to my posting. My posting is not intended as criticism of Roon. As a lifetime member of many years, I am well aware that Roon has been very upfront about system and home networking requirements to make Roon work optimally. I am a great believer in caveat emptor (buyer beware - in other words the buyer has an obligation to ensure that what they purchase is fit for their purpose) and knew all of this and was experiencing these problems from time to time before I paid my money.
However, I would have thought doing something to address RAAT stability over wifi should be part of planned development as are the many other feature upgrades that people are seeking. Given there is constant stream of postings about failed connections and drop outs (most likely due to home networking issues over wifi), I am not alone.
The only technical issue that is of interest to me, as a customer, is whether it is possible to make RAAT over wifi more stable. Given that audio requires far less bandwidth than video, I would have thought that this would be possible. But then my belief may be an indication of my ignorance of the technical issues involved in doing this. If it is technically impossible, then this discussion need not continue, if it is possible the issue then becomes one of priority for Roon development resources, such as costs versus benefits and overall client requirements.
I have three Roon end-points, two connected by ethernet and one by WIFI. The WIFI is my main listening room in an upstairs bedroom. WIFI from my AT&T gateway downstairs in our main bedroom to a Raspberry Pi4 upstairs works well. In four years, I’ve had almost zero issues with Roon. I don’t know why.
Up until a couple months ago I had AT&T U-Verse 50/12 internet. Recently they installed fiber in our neighborhood and I have 300/300. It just works for some reason, and always has.
AFAIK, the clue is in the design goal for RAAT that states:
Tight playback synchronization suitable for multi-room listening. There’s a careful line to walk here. If we demand ultra-tight (1-10us) sync, it becomes impossible to implement the system on existing/unspecialized/heterogeneous hardware platforms. We shoot to be within 1ms (and under ideal circumstances often much better), which is more than adequate for multi-room listening.
If Roon Labs were to drop that design goal then it would be much easier for RAAT to accommodate a wide range of performance of WiFi networks.
But of course, they are not going to drop that design goal - and neither should they.
Hi Paul these are good threads for discussion as we all bring different ideas and knowledge. But there is a huge difference between streaming video (which is heavily buffered) and audio which is real time streamed with a small buffer so the comparisons are not apt, even if they look like they are.
I am a believer that as long as your Core is hard wired and you have a solid network then there is no reason that this can’t happen, which is why Menzies tagged me in. It works perfectly as long as you have plenty of power in your WiFi network. If you use a Mesh network it needs to be good and have dedicated back haul and also WiFi signal needs to be strong where you want to have your end points.
Make sure you can stream much higher bandwidth than you need for times when others are using the network and as a good stress tester. If it fails, fallback to Chromecast and AirPlay if you are happy with them.
Plenty of opportunity to play with this and see what can be made to work for you.
My personal experience of WiFi with Roon has been good. I do not have a Mesh Wifi system - just a single WiFi 6 (802.11ax) router (Asus RT-AX88U) which covers the whole house. With my Laptop, which also supports WiFi 6, I see at WiFi bandwidths of between 300Mbps (in rooms with weakest signal strength) to 1.9Gbps in rooms with good signal strength.
However, my WiFi connected roon endpoints (originally 2 but now only 1) are based on a Raspberry Pi 4 - which does not support WiFi 6 - they only support WiFi 5 (802.11ac). Thus the WiFi bandwidth available to them will typically be lower. I’ve never measured it - but I would expect bandwidths of between 100 and 800Mbps to be available depending upon signal strength.
It is important to note that the use of WiFi in my household is not very prevalent - other than the Raspberry Pi Roon endpoint using a WiFi connection, the only devices connect by WiFi are the 6 android devices (4 phones and 2 tablets) and these are not typically very active. This is important because all WiFi devices connected to the same router/access point share the same bandwidth and in fact, a WiFi 5 device on a WiFi 6 network will use more bandwidth than its achieved data rate would imply (because WiFi 5 packet occupies more air time than a similar sized WiFi 6 packet).
Since all devices contend for airtime, it is important that the achieved data rate is sufficiently high - it needs to be able to accomodate the RAAT/Chromcast/Airplay/whatever audio stream with enough capacity that other traffic will not interfere with the ability to deliver audio packets within the required time. This is obviously easier for stream types with more compression and/or with lower sample rate and/or sample sizes. A 44.1/16 airplay stream requires much less capacity than a 192/24 uncompressed RAAT stream.
With regard to Mesh WiFi systems there are some issues to be aware of:
If the audio stream is being carried over the backhaul link (the link between the access points) as would happen when the Roon Server is connected (directly using WiFi or indirectly using a wire connection) to a different access point than that of the Roon Endpoint, then the latency (the time between sending and receiving a packet) will be significantly greater than it would be if both were connected to the same Access point - especially if a WiFi backhaul connection is used - as is commonplace with deployed Mesh WiFi systems.
All traffic conveyed over the Mesh backhaul is contending to bandwidth on that link. Thus is you have an audio stream being carried over backhaul link at the same time a some other high bandwith traffic, then the audio stream may be starved of bandwidth on the backhaul even if it has more than adequate bandwidth between the access points and the devices. In many mesh systems, the backhaul traffic may also content with WiFi traffic to and from the access point - which makes it particularly bad as up to three times the bandwidth may be required.
When a it is detected that a different access point to the one a device is currently connected to is offering a better signal strength, then that device may handoff to the other access point. This usually incurs a period when no traffic is conveyed and so may interfere with an audio stream.
Having said all of this there are various things that can be done with a Mesh network that can improve the experience:
If possible, use a wired backhaul connection between access points.
If you have a Tri-band Mesh system (WiFi 6E(?)), then it would be advantageous to reserve one of the 5G bands for the backhaul and make sure that all WiFi connected devices connect on either the other 5G band or the 2.4G band.
Wherever possible, make sure that devices that represent the source and sink of a data stream (e.g. Roon server as a source and a Roon Endpoint as a sink) are connected to the same access point (even if by wire) since this will avoid backhaul traffic and thus congestion on the backhaul link.
At least some Mesh systems (e.g. the Asus one supported by my RT-AX88U router) allow WiFi devices to be bound to a particular access point. Whilst obviously not appropriate for physically mobile endpoints (like phones), it may be appropriate to bind physically static Roon endpoints to a particular access point in order to avoid any possibility of a handover.
Incidentally, the issue with congestion on the backhaul connection has a direct equivalent problem with wired networks. If you have two groups of devices connected to two different switches with the switches connected by a single wired connection, then all traffic beween the two groups shares the bandwith (typically, for home networks, 1Gbps) on the link between the switches - thus even there, it is possible that high volume network traffic between the two groups could interfere with the ability to reliably sustain a RAAT connection between a Roon Server in one group to a Roon Endpoint in the other group.
A further thought has occurred to me. Depdending upon the demands that you make on a network, it may be possible to put your Roon endpoints on a different WiFi band than all of the other WiFi devices. Typically, audio streams are not high data rates (compared to other network use) a 192/24 stream requires about 10Mbps so, provided you do not have many of them active at the same time, the lower bandwidth 2.4G band should be adequate for this purpose. This would leave the higher bandwith 5G band available for all other devices where it may be put to better use.
Even with Mesh systems employing such a scheme could help because only audio streams conveyed over the backhaul connection would be contending with other traffic (and the 2.4G band tends to be more resilient anyway).
Segmenting the WiFi network in this way would avoid situations where high WiFi usage by one or more non-Roon related devices interfered with the delivery of Roon audio streams.
This is kind of what Sonos tries to do when you add a Sonos Boost. It’s a good suggestion.
@Paul_Williams For reference… I have a Raspberry Pi 3B+, an old Pi known for its not great Wifi hardware. This Pi runs DietPi and RoonBridge. It’s got a DAC hat on it clocked by the Pi. It sits on, what I consider, “the edge” of my Wifi network (think a 3 out of 5 signal strength). I resample everything down to 16/44.1 at this endpoint using Roon DSP. It works flawlessly. So, to answer your question, yes it’s completely possible for RAAT to work and work well over wifi. Even when that endpoint is a bare minimum Wifi antenna. It does come down to the network and making sure that the network band you’re using is uncontested and low propagation delay.
Compare RAAT and networks to cars and roads. A expensive sports car will perform great on a highway or racetrack, but what if you take it on a dirt road? It’s going to be outperformed by an average SUV. The engineers who designed the sports car simply did not design it to drive on dirt roads.
In very much the same way, RAAT is simply not designed to be used over Wi-Fi. Sure it might work, but it’s not something the designers had in mind when developing RAAT.
Not true. What Roon Labs actually say as one of their design goals is:
Stable Streaming over Ethernet and WiFi networks. We take this for granted now, but it’s easier-said-than-done, and a huge set of implementation choices are driven by this requirement.
I stand corrected. But the same article also states:
No support for under-specced platforms or un-proven network stacks. RAAT is built to evolve over time. We continue to improve the network protocol. We might decide to change the buffer size requirements on the device to increase stability. We might decide to build a second network protocol optimized for streaming over WAN, or something else like that. We give the same advice for users of Roon as we do to manufacturers building RAAT-based products: under-specced systems lead to bad user experiences; hardware is cheaper than ever and getting cheaper all the time; don’t over-economize if you want the best result.
So I guess I should rephrase as “Roon is simply not designed to be used over all WiFi”
) told me once, if you can stream DSD 256 on your WiFi network, then you’ve got a solid WiFi network, or words to that effect. I have one access point limited to 100mb bandwidth due to a cable issue. I can stream to one endpoint in DSD256, whilst 16/44.1 to 2 other endpoints from the same AP.
. I stand by that quote (because it helps stress test a WiFi connection for audio playback) and also agree with what 
