Switches and sound quality

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…

Summary

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 :wink:

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 :slight_smile:

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

1 Like

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.

1 Like

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!

1 Like

@Simon-in-Suffolk How do I check and then enable IGMP snooping in a Cisco 2960?

1 Like

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.

1 Like

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.