Best Practise for Roon - Networking

[Wade_Oram]

Hello All,

I would like to start a thread that will hopefully be used to distill out networking best practices to support ROON. It occurred to me that this would be a good idea because I, personally, have never had any issues with ROON that could be blamed on the network and I would find it interesting to know if there was any good reason for this.

TLDR

Brief history:
When I started my evaluation (free trial) I initialially setup my ROON core (as it was then called) on my Windows PC. Later, still within the free trial period, I migrated my core onto a Synology DS1019+ (5 x 6TB - 2 disk redundancy) which I already had for other purposes in order to remove the need to have my power hungary desktop computer turned on all of the time. Some time after the free trial expired and I had decided that ROON was my preferred Music delivery system, I configured a NUC11TNHi7 to run ROCK and migrated my ROON core to that.

Use patterns and networking
I use ROON mostly for streaming local files which are predomininantly 44.1kS/s, 16 bit CD rips (although I do have a few 96kS/s 24 bit and 192kS/s 24 bit albums. Other than for test purposes, I do not stream/play DSD.

My current network topology looks like:

The NUC running ROCK is also used to store the local library files.

As well as the ST60, the two Raspberry PI’s are configured as ROON endpoints and any of the 5 computers (all running Windows 11), 4 phones and 2 tablets can be used as ROON Remotes and/or ROON endpoints.

I have 4 people in the household, so in principle, I can have 4 ROON endpoints in use simultaneously - in practise, it is rarely more than 2 and, apart from test purposes, I can’t remember a time when I had 4 endpoints in use at the same time.

As a rule, I do not use endpoint grouping (for multiroom - but again I have tested it).

I do not use a great deal of DSP - but that is irrelevant to my use because it is localised on the core and , as I don’t do any upsampling, it does not affect the networking use profile which this post is aimed to address.

The use of the homeplug devices for ethernet over mains cabling is far from ideal - it introduces a packet delivery delay of between 15 and 70ms. Replacing the homeplug devices with another 1Gbps ethernet switch and wired ethernet connections would be much better in principle but is currently not practical. However, I have never experienced any issues related to this ethernet packet delay/jitter and it is not in any way audible.

It should be noted, that whenever I stream from and external service (Tidal and Qobuz are both used), the Tidal/Qobuz stream is delivered to the core over the homeplug network. Also, when streaming to either of the Raspberry Pi’s, the Core to Endpoint data stream is also carried over the home plug network.

The only commonly used ROON endpoint on WiFi is the RPi/DigiAmp+ streamer - but that is in a room with a strong Wifi signal so, even with the poor WiFi of the RPi, the Wifi to this endpoint is good enough to deliver reliable audio with no dropouts. Incidentally, in terms of TCP/IP packet delivery delay and jitter, this endpoint will be the worst because both the home plug mains network and wifi are used to deliver the audio stream from the ROON core to the RPi.

Network configuration

• I do not have a mesh WiFi system in place.

• Like most people I use a ipv4 class C network (netmask is 255.255.255.0)

• The ROCK (ROON core) and the two Raspberry PI’s are on pseudo static ip addresses - by this I mean that the ip address is allocated by DHCP but the ASUS router is configured to always allocate the same ip address. This is done so that, I can easily change out the router if I change ISP to one where my router is not supported without having to worry about resetting the networking on any of these devices whilst still allowing me to know the ip address for the purposes of accessing terminals and/or configuration web pages. Routers supplied by ISP’s in the UK do not always use the same class C network be default - for example, I have seen both 192.168.0.x and 192.168.1.x and if true static ip addresses were used, then changing from the first network to the second (or vice versa) would be entail more device configuration than I wish to get involved with. Of course, this would be moot if I were able to continue to use my ASUS router since all I would need to do would be to change the WAN connection details (e.g. PPPOE username and password).

• the Synology NAS and the VOIP basestation, both irrelevant to ROON are also on psuedo static IP addresses.

• I have IPV6 available but I do not explicitely use it within the home network (that’s not the same as saying it’s not used (even by ROON).

• For maximum reliabilty when using local library files, I deliberately kept the NUC running ROCK and the Arcam ST60 connected to the same switch.

• My ISP does not employ any form of CGNAT so the port forwarding for ARC was trivial.

Conclusions

This all leaves me wondering, since in some respects my network is not optimal for ROON (too much latency/Jitter to be ideal), why I have not had any network related issues when many others have - even with the update to ROON 2.0.25 (which appears to have been particularly problematic for some). Is it possibly related to the use of the pseudo static ip addresses for the ROON core or is there some other reason.

I would be delighted to hear from anyone else who could contribute to a ROON networking ‘best practice’.

[Suedkiez (Just a fellow user like you)]

@Wade_Oram

I do not use a great deal of DSP - but that is irrelevant because it is localised on the core and does not affect the networking use profile which this post is aimed to address

That depends on the DSP because upsampling will increase the data size over the network

[Wade_Oram]

True - I shall modify my statement to be more specific to my use.

[Suedkiez (Just a fellow user like you)]

@Wade_Oram

too much latency/Jitter to be ideal)

As long as the data arrives in the buffer in time, it simply doesn’t matter. There is no grading - it might be marginal but as long as it’s there, it’s there.

@Wade_Oram

Is it possibly related to the use of the pseudo static ip addresses for the ROON core or is there some other reason.

Unless a router is severely broken, it doesn’t matter how devices got their IP

[Wade_Oram]

@Suedkiez

As long as the data arrives in the buffer in time, it simply doesn’t matter. There is no grading - it might be marginal but as long as it’s there, it’s there.

That’s correct. I was just pointing out that a potential 70ms delay over the home plug link is a huge delay in home networking terms - but it still does not affect audio in any way. TCP/IP (used by the streaming services and RAAT) guarantees eventual delivery and it guarantees integrety (a packet is either delivered bit perfect or the transmittion is retried) except in the case of a broken link - but it does not make any temporal guarantees.

@Suedkiez

Unless a router is severely broken, it doesn’t matter how devices go their IP

I think the whole thread is predicated upon the assumption that networking equipment (Router(s), switches and, in my case, home plug devices) is working correctly - by that I mean working as you would expect from their configuration.

[Suedkiez (Just a fellow user like you)]

@Wade_Oram

I was just pointing out that a potential 70ms delay over the home plug link is a huge delay in home networking terms - but it still does not affect audio in any way.

Sure. I just meant that it may well have zero effect in your case, but a tiny bit more latency might lead to frequent dropouts. It’s one of those things that users with less knowledge might find surprising in the „but it worked yesterday“ sense

[Robert_F (Rob)]

@Wade_Oram, I moved this thread to the Networking category.

[AndyR (Andy)]

@Wade_Oram

working as you would expect from their configuration

I’m often surprised some ‘configurations’ work at all… I suspect a lot of issues are self-inflicted by ill-advised tinkering.

[David_Snyder]

@AndyR

I suspect a lot of issues are self-inflicted by ill-advised tinkering.

Indeed. I’ve heard multiple Roon problem reports from folks who insist on using Ethernet to fiber media converters to “improve sound quality.” Also, inserting “audiophile” switches rarely improves reliability.

[Suedkiez (Just a fellow user like you)]

It may be good in the context of this thread to refer to the official best practice recommendation, in case a future reader is not aware that it exists:

Networking Best Practices

[David_Snyder]

Here’s something I posted on this topic a couple of weeks ago. Adding to this thread to save myself some typing:

Two switches. One for core, one for endpoint?

You’ll find some good advice here: The topology that I recommend is similar to what Roon Labs describes in this article. Connect a single unmanaged switch to your internet router. Cable Core (your NAS, if you have one) and as many Output devices as possible to that unmanaged switch. If the router can also function as a Wi-Fi access point and has adequate coverage, use it to connect Control devices (eg., smartphones, tablets, laptops). Otherwise, connect one or more Wi-Fi access points to the r…

I’m not saying that other network designs can’t or won’t work. But, using a topology like the ones I describe is will significantly reduce changes for problems and make the problems that do pop up easier to diagnose.

[Jim_F]

Here’s mine. I think, for the most part, it meets “best practices.” It’s been pretty flawless as it has evolved over 4 years.

[wklie (Peter Lie)]

@Wade_Oram

why I have not had any network related issues when many others have

If your setup works, your network infrastructure is not broken.

Many network problems others reported are caused by multicast blocking, WiFi, mesh, managed switches (multicast blocking and incompatible flow control), defective (but not totally dead) switches, double NAT or ISP router plus self-bought router or mesh creating two different networks, misconfiguration (e.g. Jumbo frame, problematic QoS), VLAN (that causes problem with multicast), VPN (that does not pass multicast), problematic Energy Efficient Ethernet, Firewall (that has a tendency to reactivate after Roon upgrades for whatever reasons), failure to grant network permissions (to Roon Remote app on iOS), etc.

[MikeD (- Music Is In The Ear Of The Beholder)]

I see what you mean by “Less Is More”

Not to go off topic, but which Focal open backs do you have?

–MD

[Markus_Hubner (Banned)]

Excellent summary!

[Gareth_Beard]

I find the WiFi on RPi4b’s are a little sensitive to signal blocking so positioning is important.

I run the server in a docker container in my homelab on a segregated macvlan so it can have a whole ip to itself as I did have issues with port overlap without it.

The bonded 20gb lag into my tor switch is massively overkill so can’t comment on issues that end. The 1gb eth to the AP with wifi5 is again overkill so no issues.

I can run tons of DSP and have no impact.

[Gary_Breeden]

I have a roon nucleus connected via hardwire network. I have an ASUS Zenwifi ET8 mesh router system. I’m not overly into networking but not unintelligent. I have given up trying to get Roon ARC to run consistently. Perhaps it is my mesh system. I do not wish to change and will just continue to use tidal and qobuz apps for CarPlay. Sigh, I wish it would work. But it doesnt.

[Jim_F]

Roon ARC is finally working great for me. I think it’s because AT&T upgraded my internet to fiber 300/300 from copper 50/12 (for the same price). Roon itself has always worked great.

[wormcycle]

Of course the details of every network will vary but the only thing I do differently is that I never enable wifi on my RPi Roon endpoints, it is measureably noisy. On RPi 3 is tied to USB, on 4 wifi is supposed to be better but it is not. In my view there is nothing wrong with Roon core on wifi (I use Surface and DO NOT play music from the core) but RPi RAAT endpoints IMHO should be wired.
I use Digi+ Pro and Pi2AES endpoints and I am happy.

[Wade_Oram]

In principle, a wired ethernet network with a reasonably topolgy (not too many switches in the audio transport path) will always be preferable to WiFi because of the lower packet transmission latency.

However, the buffering in the roon endpoints is more than sufficient to make this moot unless the wifi reception is very poor to the extent that packets are being repeatedly dropped and retransmitted.

With respect to the ‘noise’ on wifi connected endpoints, I think that rather depends upon the endpoint - in particular the method of connection to the DAC. On my most commonly used Roon endpoints (an Arcam ST60 and two RPi4 devices - one connected by USB to a FIIO K9 Pro (ESS) and one with a Pi DigiAmp+ audio hat), there is no observable difference in audio quality between wired ethernet and WiFi. However, for maxmimum relibility, I run the ST60 and the RPi connected to the Fiio K9 off of ethenet and only use Wifi for the other RPi and mobile endpoints (android phones and tablets).

The RPi4 Wifi receiver is not the most sensitive and it needs to be closer to the transmitter than many other devices and it seems to be sensitive to orientation - but when it is suitably situated, it is very reliable.

I know that, in the RPi3, the ethernet and USB share bandwidth on the bus - so that will introduce some timing jitter at the IP/USB packet level - but unless it is extreme enough to cause buffer exhaustion, it should not affect the performance of the DAC

In terms of the sample delivery to the DAC, there will be no difference between wired ethernet and WiFi. In both cases the sample values will be identical and the timing of the delivery of the samples to the digital to analogue conversion circuitry will be dictated by the DAC implementation.