Hi I noticed this … thought it was very interesting…as Hans has attempted to describe…digital audio and it’s vulnerability to degredation… Why switches influence the sound quality - YouTube. On a personal note I have found better power supplies and switches made a big difference in my system…this is a very interesting account… I don’t pretend to fully understand - but I think I get it…it seems to make sense…
This text will be hidden
I’ve not watched the vid, but certainly for AES67-based networked audio (Dante, Ravenna, QLAN etc) there’s quite a bit of setup required to ensure stability - especially in larger installations. PTP clocking and QoS needs to be set correctly, as does enabling IGMP snooping. I know of at least one PTPv2 clock from an established broadcast manufacturer that has measurable levels of jitter. I’d need to break out Wireshark to look in to the protocols in use on NAS-based file streaming from an NFS or SMB filesystem and then any incoming internet streams, but I’d be prepared to bet that correct setup of a given off-the-shelf switch is as significant as any environmental factors (RF, electromechanical or power supply noise/ripple). Essentially most of us just drop our gear on a flat home network and don’t really worry about packet loss as the data rates are low.
Watch the video when you can…I would appreciate your take on it… cheers
You mean enabling IGMP snooping of course 
For those not in the know - enabling IGMP snooping removes the burden of the streamer having to process and decide whether to discard or use group addressed data. Less processing for the streamer tends to mean less interference from digital electronics and often preferable SQ.
Many so called consumer ‘audiophile’ switches use very basic switch chipsets that can’t support this sort of network optimisation and simply ubiquitously retransmit all group addresses whether they are wanted or not by the streamer - not ideal 
BTW PTP doesn’t avoid jitter necessarily - it rather is a way of precise synchronisation - the accuracy of the clock and its stability will be covered by the synchronized devices themselves between the sync points and the protocol
You are right and thanks for the correction- I should put my glasses on and ensure autocorrect hasn’t done anything unpleasant. Text corrected above to avoid confusion. There is definitely a gap to fill with network setup recommendations based upon some quantifiable metrics. Not sure if the discussion belongs on this forum, but perhaps publishing the results when done might be.
I only have an Asus modem/router feeding direct to my Melco then on to NDS. I watched the video with interest but then picked up on the point about IGMP snooping in the discussion above. Checked my router and found it was not switched on.
Up to now the difference in my system has been very noticable streamed vs locally sourced. Switching it on has closed the gap considerably so thanks Guys for the heads up!
It’s on by default for all its switch ports I believe … other than that you need to log on
If you type
#show ip igmp snooping detail
It will show if IGMP snooping operational on the switch and if you remove the keyword ‘detail’ it will list out the IGMP snooping state for each switch port which is otherwise configurable.
Thanks Simon
The first 16 minutes are a good description of why Naim put the DAC in the same box as the transport with focus on a clean environment in the original CDS, and why a SPDIF interface between transport and DAC was best avoided, and why Linn put a clock link between the Numerik DAC and Karik transport. From the description you can also see why an extremely quiet power supply that does not dip under load is also important - after all the representation of the waveform whether digital square-wave or analogue will be derived from the power supply - an area of focus for Naim. Jitter will always be an ongoing issue and I’m aware of at least one TV manufacturer that has a greater amount of jitter on data as it passed back via eARC requiring the AV preamplifier to accept a wider variation in the PLL - just to get it to work at all! For streamed audio there’s a little gap in the explanation as to what exactly is going on with data as it passes through a switch and it would have been useful to have seen some quantifiable measurements, but the implication is that the data is clocked in to the streamer containing potential timing errors, and that some streamers are better than others at nulling this out through dropping the data into buffer memory and then accurately reclocking out to the DAC.
Actually these days if correctly galvanically isolated (like Naim do) it is probably the best way along with USB3 of connecting a transport to a DAC (though SPDIF can be optical) to provide the optimum electrical decoupling - the days of DAC clocks being derived from the source transport passed us by in the 1990s - time has definitely moved on by 2023!! - and I have heard some mumbo jumbo from some hifi manufacturers on this - but luckily not from Naim who faithfully support SPDIF for those of its customers who consider that the optimum option.
Naim have to go to a some effort and expense in a single box to decouple their transport from the DAC using optical couplers, careful EM screening, multilayered PCBs and carefully having to manage clock synchronisation from the master recovery clock through DSP and into DAC which all adds to the retail price. Yes on the ND555 they are pretty successful however even there some people who still say they can hear ‘significant’ changes between ethernet characteristics and network noise - which shows by definition there is still coupling.
Since I separated my transport from my DACs, and I do use SPDIF because of its framing specification and robustness, I no longer notice sonic changes from the vagaries of the home network so by my engineering terms I consider that decoupled… but yes as an undergraduate I did learn the hard way about undesired electrical coupling in my digital designs in analogue systems - back then mostly video… and thirty years later it still has not left me…
Referring to typical local and internet audio streaming:
It will usually “just transmit data to the buffer of the receiver” by any typical data transfer protocol, most often TCP based. (Which is everything, but realtime.)
This includes the typical internet audio streaming, since they are individual streams (not broadcasts), and e.g. transmitted via HTTP(S) or other protocols.
No QoS, IGMP, or other sophisticated protocols involved - you just rely on ample overprovisioning of bandwidth (compared to low audio bitrates needed) and buffering (negligable amount of data for todays computers) on the receiving side. This removes the need to synchronize between source and playback device.
(For non-live streamed music you can buffer as much as you like in advance (video as well); and for near-real-time (like radio) you can easily afford a second or two of buffer.)
(I’m not talking voice-over-IP and other realtime applications here. Here you ideally want to buffer maybe 20ms.)
As I understand, AES67 is for real time transmission of live audio, or maybe broadcasting audio synchronously to multiple receivers. This is a different use case.
Comparable things may happen, when “multi-rooming” (AirPlay, Chromecast, or proprietary impementations), i.e. when mutliple receivers need to to be synchronoused (e.g. via PTP+RTP). But a single-ended “cosumer” receiver will ignore such protocols.
QoS is only relevant in latency sensitive flows where there is contention (with TCP). Unlikely to be relevant in home networks
IGMP snooping is the one that is relevant for many streamer transports as it keeps unnecessary data processing from group flows away from the streamer, thereby lowering the processing noise and ultimately enabling better SQ from the streamer by creating lower noise.
A true audiophile switch in my opinion must support this… especially in modern home networks with modern home appliances including home management and automation and this will only become relevant overtime… and it is appalling how many consumer audiophile switch products are marketed to un knowing consumers that don’t support this. Hence my recommendation to use daisy chain a commercial grade switch that does support IGMP snooping, upstream to filter the group flows from a basic consumer grade audiophile switch. For this to be effective you should only have the streamer connected to the audiophile switch.
Ah; to isolate the streamer from e.g. (live) IPTV multicast, which a TV or streaming client draws into the LAN. Understood.
(Not for the audio streaming as such.)
Chromecast, AirPlay and a lot ot IoT devices are rather network chatty and use multicast (mDNS) for discovery. But these multicasts still get spammed to every port and device on your network if you don’t use IGMP snooping. IPTV is where IGMP snooping comes into its own as without it your network will likely grind to a halt.
IPTV is one possible example if multicast if used in that IPTV product… but multicast groups are far more prevalent than just IPTV… just put an Analyzer on the typical home network… increasingly modern consumer products and products use multicast groups for control and discovery…
Yes some groups use addresses which are required to be broadcast irrespective of IGMP snooping as part of network standards, others use addresses that can and should be filtered.
But yes it is about controlling and preventing as far as possible irrelevant data being sent to the streamer such that it needs to analyse it before it knows whether to ignore it.
A switch handles unicast flows - such that only relevant unicast data appears on specific port segments. This is good for avoiding unnecessary unicast data being sent to the streamer. With multicast flows unless the switch device supports IGMP snooping for the relevant group flows, the switch will instead appear as a simple old fashioned network hub for multicast data. … this is not good for minimising unnecessary data processing in the streamer… relevant if ultra low noise within the streamer environment / box is wanted.
Hopefully that makes sense
“Yes on the ND555 they are pretty successful however even there some people who still say they can hear ‘significant’ changes between ethernet characteristics and network noise - which shows by definition there is still coupling.”
My network is based around wi-fi isolation so between my modem/router and the first switch there is a radio link with wi-fi to ethernet bridge.
Any changes I make to my router, be it power supply, DC cable, Atacama platform etc. I can very clearly hear in the final sound quality.
So, logically any noise anywhere along the network is leaving a sonic signature, regardless of any isolation. If I remove the isolation, sound quality gets a lot worse, but including the isolation doesn’t make the system immune to the sonic impact of noise prior to the isolation.
From the above I conclude that noise is affecting every network component, not just the DAC and that the concept of better in = better out affects the entire network, for example, the better the router’s input, the better its radio output, despite being followed by isolation.
What I would further conclude is that focussing only on removing noise arriving at the DAC is leaving a lot of potential SQ improvements unaddressed.
Yes… network specific noise is not about electrical isolation or low noise switches etc… network noise is derived from the processing of network data. If you require more processing per unit of information, the overall noise level will be higher for that unit of information.
Often with audiophile switches and the like, they don’t address network noise at all but instead address physical electrical coupling noise. But some, or dare I say many, and even some YouTube talking heads, get network noise conflated with physical electrical coupling noise… such as common mode noise and phase noise from link serial clocks etc.
Wifi like fibre will eliminate common mode noise through metallic conductors, but again like fibre will not eliminate network noise.
But I would suggest poor electrical and electromagnetic hygiene (ie electrical coupling noise) is likely to be noticeable than actual network noise which is why electrical noise mitigation is perhaps more targeted to audiophile consumers rather than real and specific network noise.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.