Yes, Richard, this is a great way of framing the issue. Thank you.
From switch (if you use one) to streamer, this is absolutely the right way to go vs a shielded cable. There are nuances re “directionally” grounded shielding, but if we’re talking Cat vs Cat then Cat 6 beats Cat 8 for the last leg.
What can go wrong is when people confuse Some Science with All Science!
Those of us who work or have worked in corporate IT are at greatest risk of thinking we have the whole truth when we have only a partial truth.
The assertion, from those thinking their partial truth is the whole truth, is that there can be no differences amongst servers and no difference amongst switches because otherwise the internet wouldn’t work, and therefore anyone whose experience is clearly otherwise is either a sucker for marketing or fooling themselves. It’s not only patronising, it’s factually untrue.
And on the flipside many of us are skeptical of the wild claims made by numerous Audio manufacturers. When one opens up a multi multi thousand dollar ANSUZ switch, only to discover there is a $30 D-Link switch buried inside, it is not difficult to deduce where the term “snake oil” comes from.
As long as the ANZUS switch was sounding better!
Go figure…
![]()
A degree of scepticism is of course understandable - the industry does have form! - but as @Erwan suggests, the starting point for any criticism of a switch is how it sounded.
Did you hear it? Did you compare it with a native $30 D-Link? Did you open it up? Regardless, a high-performing switch demands a lot more than switch circuitry, however sophisticated.
Bringing the topic back to Servers and whether or not two different Servers can have a sonic impact when connected over Ethernet.
Part of the challenge with debunking claims like this is that integrated platforms like the Rossini/Bartok/Lina make it difficult to prove beyond a reasonable doubt as the digital internals are difficult to get at, while the analog output can naturally vary minutely even when nothing has changed.
However, the Vivaldi stack makes it relatively easy to absolutely debunk these sorts of claims. The output of the Vivaldi Upsampler is all digital and will not change when playing the same source file via different Servers connected over Ethernet. That is a fact, not a matter of personal opinion.
The set-up required to demonstrate this is exactly the same as used for objectively debunking the opinion that Server Applications make difference - Roon vs Mosaic SQ - Redux - #5 by Anupc
Nobody has anything against anybody voicing their opinions, but when an opinion is countered, at least attempt to prove your point with more than just conjecture or “I think I hear a difference so there must be a difference”.
I was sarcastic actually…
Interestingly, you didn’t notice it.
![]()
You should perhaps go back and read your own replies in this very thread.
I personally suggested we agreed to disagree a couple of times - and not wishing to sound condescending myself, if somebody says that it generally is an invitation not to carry on trying to debunk and dismiss what they are saying.
But VERY happy to move on
as thankfully you now you appear to be a bit more accepting of other viewpoints and other experiences.
But by the way - I respectfully but strongly disagree with this - there absolutely no need for anybody with a different experience to provide any scientific evidence to back up what they are hearing - that’s the point of science isn’t it? …humans observe something and then work to find a explanation. Denying the observations possibility feels anti science and anti progress.
We move on! ![]()
![]()
However, you’ll notice though, in pretty much every thread I’ve seen, those with subjective opinions generally like to try and apply some pseudo-scientific explanation behind their opinion. Just look at this thread, how quickly did those who think that Servers make a difference jump onto the “Ethernet noise” bandwagon? ![]()
And to those who imagine Servers makes a difference because of Ethernet noise, let me ask you this one simple question;
- Have you ever done a firmware upgrade on your dCS unit? If yes, have you ever cared about what Server is sending that firmware?
If you believe the dCS DACs are so sensitive and susceptible to Ethernet noise to the extent that different Servers can sound different, then how are dCS DACs able to receive the firmware without Ethernet noise causing any problems whatsoever? What makes you think music files somehow don’t enjoy the same robust architecture inside the dCS unit?
Q.E.D.
This paper posted by @James is very useful. Section 2.1 in particular - Ethernet noise isn’t an issue by design and data transfer via ethernet is checksummed to ensure perfect data integrity. @Anupc’s Vivaldi up sampler experiment proves the latter point.
https://dcsaudio.zendesk.com/hc/en-gb/articles/22144834486812-dCS-Guide-to-Streaming
Back to the original topic - I purchased a dCS product in part, because of the integrated and properly engineered streaming functionally, which obviates the need for another box (at least for L/B/R)
Unless you want Roon, in which case you are unfortunately obliged to purchase another box.
Yes but this is a trivial add on. Because dCS has proper Ethernet magnetics - it doesn’t care where the data comes from. Any computer spec’d to run Roon with an RJ45 will do it. The base M4 Mac Mini can be had for less than the price of modest pair of interconnects.
Well I definitely prefer it when an interconnect shows a bit of modesty. I hate those arrogant ones, constantly going on about how good they sound.
In furtherance of @Urbanluthier ‘s helpful post referencing the dCS paper, this is, IMO, the key paragraph:
“The network connection is also more consistent in electrical noise control. There is a provision built into the Ethernet specification (the specification that determines how the Ethernet port on a dCS product works), as well as any Ethernet port on any device like switches, routers or streamers & servers work, which says every Ethernet port must have galvanic isolation. This means the input of the port must be electrically isolated from the rest of the product it is feeding. This can be done in a few ways, but the most common method with standard Ethernet ports is to use a coupling transformer. This component isolates the port – meaning there is no direct electrical link between port and product – whilst allowing data to pass through unaffected.”
Before heading on vacation I sat in in a demo with individuals from both dCS and Innuos. They were comparing their new 100k server and their current top of the line device through the Varese DAC. Everyone heard at least small differences via the USB connections they were using. I did ask what would we would have heard if they had been using DCS’s preferred ethernet connections and the answer was you would not get the Innuos “magic” if Ethernet was used.
At least they are honest. ![]()
Actually - if I may be so bold, nobody seems to conflate Server performance with Ethernet noise more regularly, more selectedly, and more enthusiastically than your good self.
And they are different factors.
You also regularly go to this “the internet would break if data wasn’t data” argument - and this is correct. But again - there is conflation and diffusion here - the internet isn’t a real time system - it’s about making sure all the data gets there, it’s not about making sure it gets there exactly when it’s supposed to and not a picosecond late. So there is another factor here - time. In a music stream - data is being read, transmitted, received and decoded in real time - so getting the best read from a disk, with the fewest retransmits and retries (I believe the grown ups call this “jitter”) is probably a good thing right? ….I wonder if there are any companies out there manufacturing equipment doing real time conversion of data streams who consider the timing integrity of data to be an important factor in musical enjoyment? …a company who take the view that reclocking the data stream that comes from a server to be a good thing to do? …know anybody like that? …anyone?
You yourself manage away Ethernet noise by using fibre. And you yourself manage away disk read performance issues by using a high quality expensive audiophile server. Your server isn’t just any old audiophile server either - it even reclocks your data for you, to ensure minimum jitter.
You’ve made some good choices - it’s a shame, and frankly a little perverse - that you’re so keen to deny these eminently sensible choices matter one jot, and even more puzzling when you so enthusiastically attempt to take down those who have made precisely the same choices as yourself.
Once again - we can agree to disagree - or we can carry on - I’m fine either way. I’m not the one with the massive contradiction on my rack.
Good point. The same with Server vendors like Taiko, IIRC, majority of their users use USB interface to their DACs. Imagine spending $100K on Supermicro motherboarded PC with a souped-up USB port ![]()
I’m guessing you’re unaware that the dCS Streaming interface is not real time either! The Streaming board used on dCS platforms is a Single-board Computer (SBC) which runs a non-Realtime Linux and operates like any other non-Realtime embedded Linux system with appropriate buffers and a full TCP/IP stack.
Sorry, technically, your argument doesn’t hold any water if you’re suggesting thats why Servers sounds different with dCS.
I use fibre for a couple of reasons, noisy mitigation isn’t one of the primary ones. Also, you’ve got your wires crossed; the Melco N1SZ doesn’t have a Clock port for synchronisation to anything. it’s a standard Buffalo NAS with an SSD in a fancy chassis/UI, which I chose because it’s physically silent. No contradiction whatsoever. You should get your facts right ![]()