Might I suggest that this is like going into an East Asian household complaining about rice? What is your aim?
5 Likes
The both can coexist perfectly fine and do for me. I use Qobuz for discovery and to play the odd album I donât have. If I like it enough I buy it. Why ? Because I donât need the internet to play my own music. I can play it on what I like not reliant on a single app or service. I can decide which master version I want, I wonât be faced with not being able to play albums as they got removed due to loss of license. And perhaps the artists get more back from my sale?
5 Likes
This is true. Streaming services pay so little to artists. One has to listen thousands of times to have the artist earn the same amount of money compared to an album sale.
Money doesnât grow on trees here so I generally wait for the Qobuz Download Fests when buying new music.
Of course the artist receives a bit less this way. But it is still a lot more than streaming the same album. Which may disappear as well.
This is exactly my setup, and yet I have had intermittent and lasting problems of Roon dropping out and freezing. Neither the support folks at Roon nor Netgear (helpful though they are) have been able to solve it.
Lightning DS is not an alternative for a large collection, I tried it before Roon (with my Aries)âŚ
If the OPâs perception is, that his roon environment is unreliable one has to accept that.
Perception is Reality.
Root Cause = UNKOWN
Solution = OPEN
Yesterday late evening I played ~2h music in my roon environment and after ~100 minutes no sound anymore. JRiver UPnP streaming does also not working anymore. I knew the solution from the past: Put the Power Plug of my Devialet Expert - wait 60 sec - Power on - everything is working again. The Streaming Client is for me and some other Devialet Cusomers unreliable - for what reasons ever (Gb Ethernet etc.). I have talked a lot with them but no final solution. My personal opinion is that it was there first streaming board and has some hardware issue which could not be solved. May be they have fixed it in their new Atsra. I will have a new streamer this year (T+A).
Coming back to the original post - without the root cause itâs unpossible to make any concrete recommendations. A network based High Res Streaming Environment is complex and if it is unreliable sometimes solutions are not simple, expensive or not even possible (in a rent flat all wired Ethernet is in most cases unpossible). I know this is frustrating!
1 Like
No, not even close. I have an Aries G2.
See âŚ
[Moderator edit: text replaced with link ⌠please do not create duplicate posts.]
1 Like
True.
I donât think that this statement gives the correct impression. Networking can be complex in anything but the simplest of scenarios but there are no additional requirements for audio - High res or otherwise. There are only two aspects that matter: Available bandwidth and latency (ping times). These same network characteristics are import to any network application (although the consequences of not getting them right can be more or less severe).
Within a home network, point to point latency should be 1ms or less for wired Ethernet but may be significantly higher when WiFi, Ethernet-over-mains or some other non-standard physical layer network transports are used. TCP based protocols impose a limit on latency that can be tolerated. If that latency is regularly exceeded the network link degrades because of re-transmissions and can break down completely in extreme cases. However, this should ever happen - if it does you have a non-functionaly network. On top of this, any audio protocol (TCP or other - usually UDP) will have limits on the amount of latency that can be accommodated although some may have tighter limits than others and the effects of exceeding this latency can vary.
Network topologies should always be designed to minimize latency - for a poor counter example, a MESH Wifi system (with a WiFi backhaul) with a Roon Server connected, by WiFi to one WiFi node and an endpoint connected by WiFi to another node will have high latencies between the Roon Server and endpoint because it involves (at least) 3 WiFi hops: Server to Node1, Node 1 to Node 2 and Node 2 to endpoint.
With respect to bandwidth, Ethernet with 1Gbps or better infrastructure and modern WiFi operating in good conditions have more than enough bandwidth (in principle) to handle audio. The caveat, particularly with Wifi, is that the available bandwidth is often not the reported bandwidth. Considering WiFi, if your WiFi is saturated with traffic unrelated to the audio stream, then the actual bandwidth available to the stream is much lower than the WiFi bandwidth as a whole. If Wifi is used on multiple hops on the same Wifi device when transporting packets from, for example, Roon Server to endpoint, then the effective bandwidth available for the audio stream is halved - e.g in a mesh system with WiFi backhaul and an endpoint connected to a mesh Node (other than the one to which the Roon Server is connected) by WiFi, you have the Node to Node link and then the Node to endpoint link both carrying the audio stream but competing for the available bandwidth. Of course with WiFi signal strength issues can degrade the available bandwidth even further as well as making it effect of the above situations more difficult to anticipate 
Even with Ethernet it is possible, with a poor topology and bandwidth planning, to starve an audio stream of bandwidth when the audio is not the only network application running. Consider the following scenario:
____ Router ____ Internet
|
Client 1: _________ | ____ Server 1
| | |
Client 2: ______ Switch ____ Switch _____ Server 2
| |
Audio EP: _________| |___ Audio Server
In the setup above (assuming all Ethernet links are 1Gbps), if Client 1 talking to Server 1 and Client 2 Talking to Server 2 use all of the bandwidth on the link between the switches (since I didnât specify audio for these, this is quite possible), then, even with Ethernet, there may be insufficient bandwidth left for audio stream to work reliably because all of the traffic streams are sharing the bandwidth of the single switch to switch link. Even worse, this may result in âintermittent issuesâ because there will be times when the switch to switch link is saturated (causing audio issues) and other times (when the non-audio client-server applications are not running) when the link is lightly used and thus the audio works without issue.
So this network topology has the potential to cause issues with audio streaming even if all devices and cable runs are working to expectations. The issue here is not related to bad network devices and/or cables. It is a poor network topology - or at least it is a poor topology for some network use patterns.
There are a number of ways to solve the issues with the above wired Ethernet topology:
1: Make sure that the switch to switch link is a higher bandwidth than than the sum of the client links on one side and the server links on the other. For example, if, in the diagram above, the client and server devices all connect with 1Gbps Ethernet (or even 2.5Gbps) and the switch to switch link is 10Gbps, the switch to switch link can never be saturated and the audio stream should be reliable.
2: Redesign the topology to eliminate the switch to switch link (e.g. use one big switch rather than two small ones).
e.g:
____ Router ____ Internet
|
Client 1: _________ | ____ Server 1
| | |
Client 2: ______ Big Switch _____ Server 2
| |
Audio EP: _________| |___ Audio Server
3: Use multiple Ethernet links between the two (managed) switches with link aggregation configured to increase the switch to switch bandwidth.
4: Use managed switches with QOS functionality so that the switch itself will prioritize the audio traffic so that it is never starved of bandwidth but, as a consequence, the performance of the other network applications (using the Client 1 to Server 1 and Client 2 to Server 2 links) will have a speed penalty as a consequence (although this is likely to be small and may not be noticeable because audio bandwidth requirements are very low).
Note - the use of managed switches in options 3 and 4 above go against Roonâs advice for keeping things simple and, if sufficient care is not taken, could cause other issues.
With regard to the impracticality of using wired Ethernet in some situations (e.g. rented flat/appartment/house), it is still possible to use a temporary wired connection (a long Ethernet cable trailed across the floor) to diagnose issues. If the issues go away when the temporary Ethernet cable is in use and reappear when going back to WiFi, then you know that you have a WiFi related issue.
Before I added inter-room wired Ethernet to my house, I used a combination of Ethernet-over-Power (homeplug) devices and WiFi and, generally speaking, I had no issues. However, when I did have an issue which could be caused by a network problem, my first recourse was to a 50m CAT6 Ethernet cable that I keep for the specific purpose of helping in the diagnosis of issues (Itâs a flat cable so it does not take much space to store). The 50m cable is long enough that it can get from any point in my house to any other point so I could use it to diagnose connectivity issues with any of my non-portable networked devices.
These days, the HomePlug devices in my network are gone and WiFi is used for phones and tablets only as a rule. In the context of Roon, these are only generally used as remotes. I do have one Rasperry Pi endpoint in the kitchen connected by WiFi but that is not used very often. Even with this network setup, I still have (and intent to keep) the 50m Ethernet cable for diagnostic purposes.
It can be frustrating if you do not have a good understanding of the nature and topology of your network and the way that the network is used.
However, often, with a combination of some simple diagnostic techniques (like experimentally replacing WiFi links with Ethernet links and, wherever possible, measuring link bandwidths and latencies in order to compare them with your expectations) and some analytical thinking (e.g for each link in the network system, does my bandwidth usage [not just audio] exceed the available bandwidth? If yes, I may have an issue for applications that require low latency), the frustration can often be minimized. Even if you reveal issues that you canât altogether fix - at least not practically, you may find that the understanding of the cause of some issues becomes clear and you can take mitigating actions so that the likelihood of issues is much reduced (e.g. make sure that an automated computer backup to a NAS does not happen at times when you may be wanting to listen to music or avoid using a particular WiFi connected endpoint when WiFi is being heavily used for other purposes).
8 Likes
I havenât used lightning ds for many years, but from I remember, the functionality of lightning ds was very good, much better than aurender, audirvana, and lumin at the time. I think I had to use upnp and minimserver to get to my local music.
Networks can be simple to very difficult to build. I did enterprise networks in 1990 for a few years and to this day, I use only wired connections on every device that I can, and only use WiFi when I canât use a wired connection. And I say this when I get low latency and 800Mb speeds from my WiFi in any room and even the garage and back patio. Most people accept the isp putting in a central router in their house and think WiFi would be good, or the isp will put in a couple cheap WAPs to see if that improves things. It doesnât. ISPs donât know how to do internal networks, neither does your closest geek squad. In my 2400 sq ft house, I use 4 mesh routers (6e) connected wired or by WiFi using their 2.5Ghz private backhaul. Then in every room with a router, I use a switch so I can hook up the tv, Apple TV, dvd player, anything else than needs a network connection so each device behaves like they are using Ethernet wired connection which gives better performance than using WiFi. I go thru a couple of mesh routers to get to my server with a mesh router using its proprietary backhaul with no issues.
I have no problems with roon or roon arc, no drop outs, no latency. I actually have a Linux server running roon but all the storage is on a Mac in another room (like a NAS) with no latencies (the only hard drive on the Linux box is for backups of roon and the os).
Thank you for your great post!
The Devialet issue does not go away if I use a 15 m Ethernet Cable ( I have tested it).
If I stream from my roon Server (Home Office, Win11 DIY Computer) to my Media Renderer (Living Room, JRiver MC Client, Win 10 DIY Computer, JCAT USB XE) in my Living room with roon Bridge->USB ->Devialet everything is fine. Itâs the Ethernet Port of my Devialet which makes problems (Itâs a well known issue and occationally happens).
My Network is : roon Server (local SSD)â Router â File Server (all wired) ⌠WiFi ⌠RepeaterâSwitch â A/V Components, Media Renderer (all wired)
So I have Wifi between Home Office and Living Room to my roon RAAT End Point. If I want all Ethernet I must damage some furniture. I can do that, but I donât want that.
JRiver Media Center in Client Server Configuration always works (Media Renderer ->USB->Devialet).
Media Center UPnP uses also the streaming board of the Devialet and has the same issues like roon. So my problem is not a roon problem.
With difficult I mean - If you have not the perfect - all wired. I think many people have this.
But I donât wanted to take over the thread.
Yes indeed. I think it was clear from your original post that you already had a good idea of the cause of your particular issue.
My post was not intended to address your Devialet issue at all. Rather, I just used you last paragraph as a jumping off point to draw attention to aspects of networking that might help anyone having issues that may, in some way, be network related.
The issues Roon users typically face arenât about latency or raw bandwidth, especially not in normal functioning home networks where latency is sub-millisecond and bandwidth is 100+ Mbps. Roon has very modest bandwidth requirements, and audio streaming via RAAT or AirPlay needs a fraction of whatâs available so unless you are constantly uploading and downloading large files there will be no bandwith problem for Roon even on a 100Mbit network. In fact even a 20mbit internet connection is more bandwith than Roon will ever need.
The actual causes of most Roon instability issues, dropouts, disappearing endpoints, unreliable discovery, etc. are rooted in network service behavior, not in bandtwith or latency bottlenecks:
The Real Culprits in Roon Network Issues:
-
DNS resolution delays or failures
Roon is very chatty with the network and uses DNS frequently. Slow or inconsistent DNS (especially from ISP routers) can cause endpoints or remotes to appear ânot found.â -
Multicast and mDNS (Bonjour/Avahi)
Roon relies heavily on multicast DNS (mDNS) to discover endpoints and remotes. Many routers, managed switches, and Wi-Fi systems (especially mesh systems) mishandle multicast traffic resulting in devices not being discoverable. Especially when there are other multicast chatty devices like Iphones and chromecast on your network Roon can become unstable. -
IGMP Snooping / Proxying
Improper configuration (or outright lack of support) for IGMP snooping and proxying on switches or APs can lead to broken multicast behavior, again crippling endpoint discovery. With many âchattyâ devices there can be multicast flooding, something Roon appears to be very sensitive to. -
Network Isolation and VLANs
Isolating networks or using VLANs without proper rules can prevent Roon Core from discovering devices, especially when control points (phones, tablets) are on guest or isolated networks. -
Power-saving / Roaming features on Wi-Fi clients
Many Wi-Fi clients (especially mobile remotes or RPi-based endpoints) aggressively drop multicast traffic or go into sleep states that disrupt Roon communications. âSmart roamingâ features can silently break things. -
Multihoming / Multiple Interfaces
Having the Roon Core with multiple active interfaces (e.g., Ethernet and Wi-Fi) can make Roon âseeâ the wrong IP or interface for multicast broadcasts which breaks the connection with endpoints
So while itâs great to optimize latency and avoid saturating switch uplinks, those are not the root causes of the vast majority of Roon problems. Unless your home network is completely dysfunctional (which, as the post suggests, should never happen), these arenât relevant factors.
Instead, any advice or troubleshooting for Roon networking needs to focus on:
- Proper multicast support
- Clean DNS resolution
- Simplicity (avoid over-engineered or segmented networks)
- Avoiding double NAT, isolation, or complex mesh behaviors
3 Likes
My issues have never been Roon doesnât work. Just that what works doesnât work well enough or has bugs that have been ignored or take so long to fix it becomes frustrating. When ARC was crashing core regularly for many users it too so long to get to the bottom, it seems to take a lot of users to moan for them to take it seriously. As per usual everyone says it must be your network it works for me. Well no after over 12 months it was a bug in Roons LastFm implementation causing it. As likely not everyone uses this part of Roon it didnât affect you but to those that did it was painful. This is why to dismiss as many do that Roon works for me is likely your not using it in the same way as ones it doesnât. You may have never used its library exporter to move files and would not know it bombs out and crashes core after it reached a certain track count. Still donât know if they fixed this.
Other areas are down to how itâs been decided Roon works, and are design decisions coming back to haunt certain users. Such as constant metadata trawls for music that doesnât and never will have any, processes running out of control due to this, database oddities, tags seem to cause more problems than they solve. I like a few others lost ability to use a tag I had used for years for no reason. Roon stopped accepting adding it to any new music, yet all the existing ones worked, could they give me an answer no.
There have been issues with spurious album counts and duplicate albums that donât exist for over a year ( maybe finally fixed) . This coupled with half baked new features that take months to properly fix. Last one being Listen Later not being able to remove albums once listened to if added to your library. None of this is network related or kit related itâs down to bad code.
Whilst many users it might be bad network setups or network features interfering with discovery there are plenty other areas Roon doesnât do well. Itâs not perfect guys the fact some have to revert to other apps to manage large boxsets is proof of that.
2 Likes
So where is Roon v3.0 ?
3 Likes
I agree but I would guess for most of all roon Users this is a book of seven seals.
Do you kow a simple test application which looks at this topics and give recommendations how to fix this kind of issues in a Users Network Environment?
To that list I would add library architecture. Large directories, deep directories with many branches are regularly reported as causing issues. Network instability is an issue for sure but my experience is that it is often the data layer as encoded in the roon library structure that puts the network handling under stress and is a more common source of issues than realised. Libraries do not have to be particularly large for these effects to be observed.
1 Like
DNS can be a problem but, if the advice from Roon is followed the rest of the points follow fairly naturally.
Roon do not recommend manged switches (and other professional/industrial grade networking items) not because they donât work but precisely because they need a greater understanding of networking to get right.
Unmanaged switches do not do IGMP snooping. This means that multicast packet handling decays into broadcast packet routing which is not ideal for a network since it means that every device on the network receives all multicast traffic instead of just the multicast traffic it is subscribing to which puts a slightly higher load on the devices and consumes additional network capacity. However, in a home network environment, the extra burden due to this mishandling of multicast (treating it like broadcast) traffic should not be significant. If you have so much multicast traffic occurring that it becomes an issue then there is probably something else wrong as well.
Simplicity. Well, no matter what the scale and scope of a system (including networks), keeping it as simple as it can be is always a good idea. However, âsimpleâ is a relative term. For some, it will mean a single consumer grade router (possibly the one supplied by their ISP) with everything connected directly to that router (either by wires or by WiFi). For others with much more demanding requirements, it may be a much more extensive network using a professional grade router and managed switches with multiple WiFi access points (MESH or otherwise) so that they can support VLANâs and traffic management (QOS and traffic shaping) throughout their network. For many it will mean something in between - A consumer grade router and WiFi access points forming a MESH) and, possibly, an unmanaged switch or two.
I donât know much about the merits of different WiFi MESH systems. I have never had to use them. However, I suspect that one of the problems seen is likely to be the combination of a MESH WiFi system with IGMP snooping combined with WiFi connected devices in areas where they may change the access point that they are associated with. If such a device migrates from one access point to another, in the presense of IGMP snooping, then it could result in multicast traffic for groups to which that device is subscribed being mis-routed which could cause problems. The presence of the MESH WiFi obviously makes things much more complicated for the correct routing of Multicast traffic and imperfections in the IGMP implementation (of the networked devices and the WiFi access points) may lead to issues that are much less likely to be seen if IGMP snooping is not used. Unfortunately, IGMP snooping done correctly also offers more significant advantages for heavily utilised WiFi ( providing a shared bandwidth) compared to the more basic âtreat multicast as broadcastâ approach of consumer grade equipment. IGMP snooping in home sized networks, even large ones with complex usage patters, does not, generally, confer the same significant advantage on wired network (because, usually, the multicast traffic on a wired network is not competing for a shared bandwidth to the same degree).
Double Nat. Well this is always undesirable within the network of a single home and should be avoided - this is just âKISSâ. Sometimes, however, it it not within the power of a householder to avoid - e.g. appartments/flats that share a common internet connection with a primary router providing different connections to secondary routers in each appartment/flat - or indeed the use of CG-NAT by ISPâs. Whenever multiple NAT situations occur, the issues around running any kind of internet facing service become considerably more complicated.
Segmented networks (either physically segmented or byVLANs) can be usefully employed (e.g. for separating IoT devices from you main network) BUT you have to understand all of the implications of the use of a segmented network and, again, the segmenting must be carefully though through. If you find yourself trying to manage a myriad of inter segment routing rules and/or IGMP proxies (to reflect multi-cast traffic between segments), then maybe your segmentation is either not correct or inappropriate.
Understanding these issues is essential to managing anything but the simplest of networks. Like just about everything else, the degree of knowedge required increases exponentially with complexity.
8 Likes
I had an managed switch from the start of my roon journey 6 years ago. It has worked up to last december (stopped working) and I replaced it by an unmanged switch. The managed switch had the advantage to set the port speed to my Devialet to 100 Mbs (Devialet sometimes does not work with 1 Gbs ports - not all users have that problem)
I was not aware that Unmanaged switches do not do IGMP snooping.
I orderd today a new managed switch and will give it a try again.With the managed switch I had no roon issues.
Many (most?) managed switches are supplied with a default setup which behaves like an unmanaged switch - including having IGMP snooping disabled. Unless you specifically enabled it, it is quite likely that IGMP snooping was not used with your previous managed switch.
Unless you can unequivocally say that the broadcasting of multicast packets is causing an issue, I would not worry about the lack of IGMP snooping. Unless your network is flooded with broadcast and multicast packets, Roon (and other network applications) will work quite happily without IGMP snooping. It is poorly implemented or poorly configured IGMP snooping that causes the problem.
1 Like