Question regarding network communication

I have been experimenting with connecting my Roon ROCK (NUC7i5) through ethernet cabling to my Auralic Aries (I used to connect through WiFi as advised by Auralic). And this has resulted in a question about network communications.

I have both my Roon ROCK (music is stored on an internal SSD) and Auralic Aries connected with high quality AudioQuest ethernet cables to a dedicated gigabit switch. The switch is connected to my router. I was wondering how the ROCK communicates (streams its music) with the Aries.

Is there a direct connection between the two? In other words, does the ROCK stream its music directly to the Aries? Or does it gets transferred to the router first? This is important as I only have high quality ethernet cabling between the ROCK and Aries and not between the switch and router.

I have conducted some experimenting on this part by pulling the ethernet cable between the switch and the router while playing music. Half way during the second song Roon gave an error about communication errors. I am unsure wether this is due to the music not being able to be streamed or wether Roon bugged out for it not having an active internet connection.

I added a simple schematic of the test setup, the red arrow is the ethernet cable that I pulled during this experiment. Thanks in advance.

This is irrelevant. Good quality standards compliant ethernet patch leads (aka high quality ethernet cabling) are necessary throughout your network. :slight_smile:

However, to answer your query, and assuming you’re not streaming from TIDAL, when the ROCK wants to send data to the Aries it will communicate with the switch, which will determine what port to send the traffic to. Once it knows this it will communicate directly with the Aries and forward data to it.


Reading your reply makes me realise I was a bit blunt on this subject. The cable between the router and the switch is a CAT 5e cable, which is sufficiently isolated I guess. It is just not as well isolated and ended as the AudioQuest cable since I use Telegartners plugs.

But thanks allot for your response! I was expecting it to work this way. But the error message in Roon made me a bit insecure about the matter.

Roon pulls data from the Internet, so that may be what caused the error message. BTW, those Telegartner connectors are designed for field use. There’s no benefit in using them in your scenario.

Thanks again Martin for your reply. I got the idea for using telegartner plugs since audioquest uses them as well in their more expensive line of ethernet cables. Also there is a fairly good review on artsexcellence website about ethernet cables and plugs.

Likely because they are substantial and look good. They’re designed for quick connection in the field, not for “audio” ethernet cables.

I am unsure wether this is due to the music not being able to be streamed or wether Roon bugged out for it not having an active internet connection.

  1. Roon not need internet connection to stream music from local discs (internal/external) or local network. Only to stream music from internet.
  2. Music can be streamed directly from Roon Server to Roon endpoint if Roon Server has internal network bridge or ip forwarding (as ROCK) and endpoint is connected to one ethernet port and router to another - after start playback ethernet cable between Roon Server and router may be disconnected.

It’s not quite direct because of how the ethernet protocol works.

First Roon will want to send a packet to the Aries. The kernel on the machine (doesnt matter the platform) will send an ARP-Who-Has out it’s ethernet port. The ethernet switch it is connected to will see this packet and broadcast it to every port on the switch other than the one that sent it. This packet contains a query that say “if you have or know of this ip, please tell me the MAC address where I should send the packet to”

In your case, the Aries will reply with an ARP-Is-At packet saying “I am IP X, and at MAC Y”. That ARP response is also broadcast to every port on the switch and anyone listening there will take note that X is at Y (in what is called the ARP cache).

Now, whenever anyone needs to talk to IP X, they will send out the packet to MAC Y, which the switch will know is on some port. Let’s say the NUC is plugged into port 1 on the SG105 and the Aries is on port 2, and the Archer is on port 3. Because the switch got the packet from port 1 and it is destined for a MAC that it knows is on port 2 (because of the ARP-Is-At), it knows to send it ONLY to that one port. Port 3 (the Archer) will never see it.

There is something called an ethernet “hub” that differs from a ethernet “switch” in that it always broadcasts all packets to all ports. But those devices don’t really exist anymore and they cant sustain high speeds. On these old hubs, a maximum of 10mbps, maybe 100mbps is reachable. To do 1000mbps, you need a “switch”. Sometimes these are referred to as dumb hubs and smart switches, but that’s confusing because there is also “managed” switches which generally have more advanced features, usually just causing trouble unless you really really know what you are doing. Managed switches sometimes are referred to as “smart” as well. I know, annoying.

As for your ethernet cable: If you believe that the ethernet cables matter (not everyone does), it has to do with EMI/RFI noise interfering with your DAC (or something else) and not the digital bits being transferred. In which case, all the cables and all other things matter, whether they are connected (EMI) or even if they are nearby (RFI).

Before anyone tries to argue the “bits are bits” topic with me, please read the post linked below and the one I made 2 after it:


Thanks @danny really appreciate the information. I like the way you teach your stuff.

How long will an ip-adress be stored in an ARP table before it gets updated? Because after reading your explanation I got the feeling that the ARP thingy has nothing to do with the error that i am experiencing in my experiment. Am i assuming this correctly? Cause I would still have expected Roon to continue playing when pulling the ethernet cable. Unless an ARP table gets resetted every 5 minutes, but this seems highly unlikely to me.

This is indeed the sole purpose of me using higher quality ethernet cables. Better shielding and better isolation.

Be careful with this one, as the shield can sometimes potentially be a nice pathway for a nice leakage current / ground loop (RF pickup and radiated, potentially affecting analogue components).

Audiophile cables are often shielded. Some makers are aware of this potential problem and at least disconnect the shield at one end. Others are clueless and have the shield connected to metal connectors at both ends.

I’m no expert in any way but I prefer to use unshielded cable and prefer to block the leakage currents upstream of the networked endpoint/DAC.

Thanks for the information Sean. So basically what you are saying is in order to shield the cable properly, one side of the ethernetcable should be ended with the shielding metal wires connecting the telegartner plug while on the other end the shielding should be isolated from the metal connector?

Does it also matter which side is disconnected from the shielding?

Hi Martijn,

To be clear I’m not qualified to give advice on the best shielding method and I wasn’t talking about best shielding designs at all.

I only brought up ‘shield disconnected at one end’ to say that some audiophile cable makers have at least thought about blocking the leakage current / ground loop (by breaking the shield connection).

As I mentioned, some audiophile cable makers actually make their cables with shields connected to metal connectors at both ends - unfortunately this may potentially be a nice path for leakage current / ground loops via the shield. Whether or not this potentially affects anything (sound quality) in one’s system, who knows. I’m very careful not to claim that anything will affect performance and SQ. We’re just talking potential technical mechanisms.

I don’t know which end is best left disconnected or if in fact a ‘floating shield’ design like Belden’s 10GX Cat 6a cable (shield disconnected at both ends) is best - I’m not smart or qualified enough to give advice there sadly :disappointed_relieved:

As mentioned, I prefer to block leakage current / ground loops upstream of the networked endpoint (and analogue components). I leave the rest to the differential design of the ethernet cables around the listening gear, so these ethernet cable can be unshielded. Sounds great in theory anyway :grin:

1 Like

Alright got ya! As usual it all depends on AB. To me AB are a bit tiresome, I would really like to steer in the rulings of physics. Makes things allot easier IMO. :slight_smile:

1 Like

Agreed 100% :grin:

Simply put - twisted pair cables, routers and switches do NOT carry “sound” but digital information about sound, cast in Ethernet frames. And these information, stored in Ethernet frames, definitely could NOT be deformed in any way in its path - it’s a main Ethernet rule.

If any deformation would be possible then e-Banking would be impossible…

So - regardless of cable or route all the digital information, in every frame, reaches its destination (DAC input) always with no any deformation - Howgh!

There is no “sound” until Ethernet frames would reach the DAC - in DAC the information is turned to music, with more or less destruction…

your Aries should be connected wirelessly. this is best isolation from the rest of the network.

Thanks guys for your replies and advise. It has once again become very clear to me that there are lots of different opinions about digital pathways and their relation to SQ. Gotta love our fiddling with possible snake oil when our hobby is mainly driven by emotion felt while listening to music. Sort of puts things in perspective…

Wether or not the Aries benefits from a WiFi connection sonically I have to say that the increased performance and stability of Roon with ethernet cabling is quite noticeable! So for now I am going to stick with the physical cabling.

Nevertheless many thanks for the info. Oh and @danny would you be so kind enough to answer my last question about the ARP-table? Really interested in the answer. :stuck_out_tongue:

The ARP table maps MAC address to IP address and entries expire typically every 4 hours. The MAC table is used by the switch to map MAC addresses to a specific interface on the switch. These expire every 5 minutes.

Would that explain why Roon bugs out when pulling the ethernet cable between the switch and router? It does appear to happen around the time frame of 5 minutes.

If you’re playing local media and Roon Core, your media repository and DAC are all connected to the switch I’d expect music to continue playing. Roon may complain (error pop-up) about a network error if you navigate to Overview, Browse etc. because you have no gateway (Internet connection.)