Perhaps I unconsciously mirrored the advertisements, possibly from my dealer in the US, Gene Rubin, who sold me one. I bought it from him, mainly to see what the hype was about, although I did not expect it to do much except just as a harmless network switch, and later sold it to another victim with almost no loss of money on Audiogon. Gene later stopped selling it for some reason, maybe not much positive feedback from his customers.
I am not directly familiar with the standard ZyXel GS-108B board.
That’s just the switchboard inside the EE8 (and several other “high-end” audio switches), it contains the switch fabric, ports and all the electronics that make the switch. It’s also what’s inside of their own switch.
Now I’m not trashing the product, I do believe it is perfectly adequate for audio applications. In fact, I own a Silent Angel Bunn N8 which is basically the same. What bothers me is how they trick people into believing it’s something special when it’s clearly not.
That sounds right; I am fully confident your point is accurate.
I’ve had the Linn next-generation Klimax DSM since 1921, so I’ve moved away from the copper Ethernet I used to focus on before 2021. I’m one of the lucky few who can feed optical Ethernet into the streamer, and I sometimes switch to Wi-Fi just to compare how it sounds on certain tracks.
Indeed! For the avoidance of doubt and all that… Ethernet is asynchronous, with packets being error-checked and if necessary re-sent; they are buffered at the streamer too. So while every switch incorporates a clock in order to function, if any one suggests that a higher precision clock brings audible gains then they don’t understand how ethernet works.
The Zyxel is probably one of the better stock switches as it runs pretty cool and pretty quiet. LED drivers don’t exactly help the noise-mitigating cause but the EE8 has these too. However, the latter’s case is far superior, being aluminium with no vent holes vs steel with vent holes.
So even if the EE8 does share the Zyxel’s circuitry, I would expect it to sound quite a bit better. As you suggest, whether that difference is worth the extra £/€/$ is up to the individual.
It’s worth understanding which I am confident you do, when it comes to ‘network noise’ .. there is no difference between twisted pair (what you refer as copper) and fibre. Network phase noise from switch clocks is identical, low level network data is identical, data processing noise is identical.
What is different of course is good old analogue common mode noise.. fibre has none. Using a mains earthed switch mitigates but doesn’t always eliminate with twisted pair. Yes there can be physical induced voltage reflections and emmision on twisted pair from in accuracies in the twisted pair cable, and or interfaces, this is the same as for USB for example. Fibre doesn’t have this. But instead can bounce or reflect light adding noise to the physical symbol signal which is likely not relevant for home audio.
Fibre is microphonic and so can induce phase modulation (effectively noise) from the audio volume in your listening room. Twisted pair effectively doesn’t do this.
It’s horses for courses. One is not necessarily better than the other. It depends on the use case and environment on which is the most optimum. I suspect for most, other variables will be more significant.
That is why I have suggested manufacturing vendors consider using SFPs on interfaces, since SFPs can be fibre or twisted pair.. as per taste or requirement.
You are right to call out that the marketing to non technical consumers conflate these matters.
The clock that is being referred to, but seldom is a uurately, is the physical analogue symbol clock. Noting to do with network data, packets, audio jitter blah blah.
This is the clock that is used to synchronise the the transmission of the symbolised voltages through the twisted pair cables or fibre. This is the clock that is synchronised to by the peer host… and indeed the host has its own clock for its symbols back to the switch.
All of this really is irrelevant other than… and this is the key part.. this symbol clock if it produces phase noise, and all do to greater or lesser extents, this will be conducted, and coupled by the host interfacing electronics. In closed systems this will induce tiny perturbation signatures on powerlines and ground planes and even EF emissions depending on designs. This as we know through closed systems engineering principles will be added to the signal in the receiving where things like ground planes, powerlines and EF may affect audio circuitry… to the point where it is above the digital audio or analogue audio noise floor.
However, perhaps an easier to understand way to illustrate that misconception is to show how a Naim streamer gets a typical CD quality track over a network…
So what you see above is the streamer loads the track into its buffer very quickly, and then network activity is minimal until it’s time to get the next track.
So, in that circumstance, how does the claimed ‘timing improvement’ affect the playback of a track?
Edit: And I don’t mean to generate a detailed technical response to that I just mean that people should realise that any benefit they hear from using a switch that claims some of these things is down to something other than ethernet timing/accuracy.
yes, that is is the high level user data - and not directly associated to the symbol values seen on the fibre or twisted pair link - but there is an indirect association. To get that user data there is much ‘chatter’ and communication on the network link which in itself is encoded into analogue values for transmission via light or electricity.
Your graph shows the consequence new algorithm Naim introduced with the second generation streams using the StreamUnlimited network interface module.
The previous algorithm was more bursty throughout the duration of the media.. I might have some pcap traces some where from back when I was helping Naim. One side effect of the old algorithm was that UPnP source including its operating system could affect the audio quality in the first gen streamers. This ceased to be by design with the second gen
See EE8 Switch - #49 by Simon-in-Suffolk for an explanation. But hint it’s nothing to do with audio timing… other than in an extremely convoluted sense.
If I am honest with myself, in my listening room, the hi-fi setup with the Linn network streamer sounds slightly softer over Wi-Fi; it is nice, but it can feel a little less engaging during long listening sessions.
Yes, indeed. What you said has a real physical basis, but it does not establish that music playing in a room makes optical Ethernet sound better or worse than twisted-pair Ethernet. Even if vibration altered the timing of received Ethernet symbols slightly, symbol timing is not the DAC’s sample clock. A streamer buffers received data before playback, so a timing change on the network does not by itself become audio-frequency phase modulation at the output.
They don’t understand, maybe. But manufacturers do understand the importance of the quality and performance of the clock, the why they in corporate cxo or ocxo clocks inside the switches. Or add an imput to connect one.
Many have added Afterdark, Cybershaft or Mutec clock to their switch and observed noticeable improvment.
Or everybody is wrong, the manufacturers and the listeners….
It can do.. fibre and twisted pair have pros and cons… but I suspect the interface componentry on the streamer has more of a bearing rather than the network medium itself.
But sure use what ever you prefer the sound of in your room / setup.
But yes correct the symbol clock has no direct correlation with a sampled audio bit stream clock.. but phase distortion power in one clock can couple into another clock in a closed system of course.
That’s only part of the story, though. As Simon mentioned above, there is still “chatter” going on throughout, but in addition, the track loading into the buffer only happens all in one go when 16/44.1 content of not much more than 3 minutes is played. More than that and the 50mb buffer fills up, and is topped up continuously as the track plays out. This will be the case on virtually all 24 bit tracks, classical music where so-called tracks tend to be longer, and most regular tracks over 3.5 to 4 minutes. For example, here are 3 tracks playing on an NDX2: the first is longer, and the other 2 are short, but they are all just 16/44.1:
I guess what I was badly trying to represent was that the timing of ethernet packet transmission has nothing to do with the timing of any audio being played, and packet transmission tends to be quite bursty. Also, I don’t think I’ve ever heard anyone notice that audio quality degrades with increased network transmission, any impacts from cable or switch changes always seem to be described as constant.
Personally I would never characterise network packets as noise, chatter maybe. For me network ‘noise’ means any kind of electrical noise you don’t want in the system, and I think it’s in this realm that different switches and cables mainly have their impacts.
noise argument aside you can test this using iperf3
I’ve run a few tests to see if my WiFi would be suitable for streaming, the challenging one is Roon that sends lots of packets as it does almost no buffering to allow tight sync between playback zones.
but TBH a network would have to be really really chattery to have impact on audio streaming.
I just mean that people should realise that any benefit they hear from using a switch that claims some of these things is down to something other than ethernet timing/accuracy.