Ethernet Connection

Do bits, bytes, 1, 0, routers, Ethernet cables matter if the DAC receives the correct 1 and 0, checksum or something like that?

Feeding the Bartok the same data from Qobuz directly to the Bartok sounds noticeable better than through a Roon Nucleus to the Bartok, both on the same network, but different wireless satellites.

When the Nucleus is attached to the same wireless satellite as the Bartok, such that they both are hardwired to the same Ethernet switch… there is no difference in sound.

Data enters my network through a Verizon 5Guw wireless internet Gateway, then through a VPN router, then to a Orbi base station, then to a couple of Orbi satellites that everything in the house connects. All audio and video is hardwired to an Ethernet switch attached to one of the satellites.The only devices connecting wirelessly are mobile devices.

How you feed the Bartok data seems to matter. Any thoughts?

It does sound different. Bits are bits, but what you hear is a lot more complicated than that because, for example, there are different paths to playback and different conditions (eg possibly different levels of electrical noise).

When you play via Roon, even if the data Roon is sending to your DAC is exactly the same as the one the DAC is directly pulling from Qobuz, the two paths and software chains are different.

1 Like

The paths are different because the code that encapsulate/decapsulates the streams are different - UPnP, vs. RAAT. However, if you and I were to download a particular file from the Internet, the file contents will be exactly the same regardless of the fact that the packets take very different paths, and could be encapsulated via very different protocols.

TCP ensures the payload is completely independent from the transport path/route/encapsulation. It’s the foundation of how things work on the Internet. If that wasn’t the case, the Internet as we know it would break down completely.

That said, IMHO, this has become a “religious” debate and people who insist they hear a difference won’t be convinced otherwise even in the face of absolute objective evidence. So, I’ll leave it at that :slight_smile:

(By the way, when a track leaves the dCS S800 Stream Boards as an I²S stream, it is bit-for-bit identical regardless of whether you streamed the track via Roon or UPnP, it has no “knowledge” of it’s transport origins)


Thanks Miguelito and Anupc, I appreciate both responses. I was not aware of UPnP, vs. RAAT, and didn’t intend to bring up a subject that has been previously discussed.

Just FYI, I currently hear no difference between music being played using the Roon app or directly to the Bartok using the dCS app. The Nucleus and the Bartok are currently both connected to Orbi satellite 1. It was only when the Nucleus was connected to Satellite 2 and the Bartok to satellite 1 that I thought I was hearing a difference.

Thanks again, for the information.

1 Like

The files are identical, and yet when played through different playback chains they sound different.

A few days ago I setup MinimServer to serve files. Roon also serves these same files. So I can play a file via Roon or via Mosaic over UPnP. The file in question was Shuggie Otis’s “Purple” (from the redbook album “Freedom Flight”). Same file. Sounded very different over Roon vs Mosaic. Like shockingly different, not subtle at all.

Assuming your Roon Core is not doing anything funky and set to be transparent, and your RAAT code is properly updated (it’s self updating via the Roon Core), then I suggest you blind test yourself.

I fell for the exact same issue a couple of years ago; I use a Melco for most of my local files via both UPnP and Roon. Roon playback is routed quite separately over multiple additional Ethernet Switches via a Roon Core in my Store-Room.

Turns out the difference I “heard” in Roon/RAAT vs. Mosaic/UPnP disappeared when I blind tested myself, no better than 50/50. And it was easy to objectively validate that regardless of Roon or Mosaic playback into my Vivaldi Upsampler; the AES bit bitstreams into my Vivaldi DAC were always identical; no PCM bitstream difference, and no jitter difference.

When you think about it, to suggest there’s a difference implies the dCS folks have got their streaming hardware majorly faulty, especially when they certified Roon Ready hardware support, because it’s easy to validate whether the payload has changed in any way.

1 Like

This one you don’t have to blind test. It is shockingly different as I said already.

Then I would definitely check if your Roon Core is running out of CPU or Memory headroom or something.

Both Roon/RAAT and Mosaic/UPnP are routinely able to transport tracks bit-perfectly to the dCS platforms. And noise and timing is inconsequential because the packets are asynchronously error detected/corrected, buffered, unpacked/decoded into PCM/DSD, and then clocked synchronously as I2S to the separate FPGAs subsystems.

In a properly working dCS setup, there won’t be any difference between Roon vs. UPnP playback.

1 Like

No CPU issues. It is redbook and I am not doing any DSP at all. Maybe you need a more resolving system… :slight_smile:

Nah, I just need better imagination :rofl:


I have tried MANY switch boxes and ethernet cables. They make a HUGE and fundamental change to the sound

1 Like

What is your top X?


What I have now is …

Entreq switch/power supply to Nas and router attached to that and drain box
Shunyata 7m ethernet to upsampler from the Entreq switch

That is not cheap but I just would not go back
My location is absolute rubbish power supply - so I have to intervene a lot!

If you want a cheaper option, the BEST by far of the rest is my Ubiquiti unify switch
Interestingly, It runs off a higher voltage than the average switch. I have sourced a better aq power cord which (if I used it now) may improve it too.

I have tried so called specialist audio switches - for me they either killed all the air or dynamics, or were ineffective IN MY SCENARIO