Chord Ethernet cables

At least not intentionally then .

Thank you Huge for bringing this up.

I don't find this controversial at all, but I think there's something more to it, namely the difference between altering RFI, and rejecting/removing it.

In layman terms, and if you allow me an analogy about what you're saying about RFI, it's like using the blur or sharpen functions in a image-enhancing software. Except that you theoretically have, with audio replay, access to the best possible image, that is what's in the recording encoded in the digital files (this is very controversial, I know, but bear with me). If an image is blurred, you can sharpen it, but it won't be closer to the "reality" (in this analogy, I think the reality would be the same photo with the same shooting parameters, but a better resolution; not the reality as seen live through your eyes). For this, you should unblur it, if that was at all possible.

Maybe I'm deluded, but there must be a way to lower the amount of RFI that enters the system (unblur or unsharpen), not just masking it with some opposite effect (sharpen or blur). I tend to think the former happened when I changed from UTP to STP cables (better RFI rejection, as Mike, Simon and you seemed to agree), and the latter happened when I introduced C-Stream cables.

Yes, that's so, and a reasonably good analogy, however there's a little more to it.  RFI isn't only getting into the system through the cables, it's also being pushed in through the mains power leads, and being generated internally in network components such as switches and NAS drives.

In respect of Chord C-Stream, that is a shielded cable and a good one, with good rejection of external RFI.  However it is Cat-7 and that means it can transmit much higher frequency signals without loss.  The down side of this is that, if there is low level RFI generated internally within the switch (for instance from it's dc-dc power converter), then that will be faithfully transmitted to the streamer!

After half an hour walking around my lower paddock,  I might have the answer to my own question.

My LAN with its 3 armed ethernet centred on the switch has ferrite on the ends of all the arms & additionally all the incoming power is also ferrite (over) loaded,  so it might be I have low levels of background RFI & don't have so much to kill off & so grounding the switch has little effect.

Whereas you might have higher RFI & grounding the switch might be zapping it & give a more significant improvement. 

And getting back to the crap-shoot m0omo0 your reply seems to indicate you think its a derogatory word for inferior equipment (craps is the famous USA table dice game - shooting crap is rolling the dice - or slang (in this case) for taking a gamble on the unknown) 

I don't think anyone around here has the answer to all this stuff,  a best switch in one system does not always return the same results with other cables or interactions with different other LAN components.  Maybe why you found C-Stream less than rewarding - & I know others who are totally opposed,  real 180 degree yea's & nay's - great fun . 

Good screened components reduce the effect of EMI (RFI from external sources), as does the use of ferrite chokes on cables, however the effect of ferrites is much more frequency selective.  They greatly reduce a broad range of frequencies but have much less effect outside this attenuation band.  These measures only reduce what is known as common mode interference, they don't stop differential mode signals.

Good design of networking components and their power supplies minimises the internally generated noise. 

Mike, good observation - a very viable hypothesis.

Your mains filtration system may also be helping here.

Oh, thank you ! That's a credible explanation. That explains why I could also hear a difference when I changed a generic Cat.7 to a generic Cat.6 between the Mac mini and the switch (Cat.6 was better). It may have brought noise from the Mac mini. The C-Stream brought a lot more noise than the generic Cat.7 then, if it's the explanation (and the effect was opposite: generic was brighter, C-Stream was softer and blurred). So if I wanted to test this, I should try to mitigate RFI on the Mac mini (and its external disks), then reintroduce the C-Stream. I'm not sure I bother though, first because the Mac mini has always been intended as a cheap temporary solution (it was donated to me, and I already owned the external drives), and second because the sound is so thrilling at the moment that all I want is to quit fiddling ! But thank you very much for pointing me in a possible direction.

Let me bring in the Black Helicopters as an supplemental explanation: regardless of the hows and whys, I'm willing to bet that Chord, being what they are, aimed for a specific sound. I very much doubt the maker of my generic Ethernet cables even knew this was possible.

Oh ! You mean craps ! Indeed, it totally escaped me, sorry about that.

As for the gamble, I agree. Not sure about the fun part though...

Still struggling to understand all this, but I tried a ferrite choke at the streamer end of my then UTP Ethernet cable, and the effect was roughly the same as introducing C-Stream at the other end of the network: blurring and softening of the microdynamics. I detested that. I thought maybe the ferrite altered the main signal as well (although this signal being an analogue square wave encoding digital information, I couldn't see how it could), but you say it is not the case (Ethernet over TP is differential, if I understand well). The effect of the ferrite was reduced when I switched to STP cable, but still went in the wrong direction for my tastes. Another head-scratching moment, considering the general praise for the ferrites on this forum.

I think you may have a case where a little RFI of the right spectrum is helping to correct the balance of your system.

On a Cat 6 Ethernet cable that's only carrying 100Base-T then the the only effect a ferrite can reasonably be expected to have is to reduce the amount of common mode RFI over a range of frequencies (typically ranging very roughly 1-300MHz, maybe less).

I'm not sure this is comforting !

2nd thoughts & another wander to the paddock followed by a probe at my switch with a Fluke 79;  I have more cats to put amongst the pigeons !!!

The Netgear GS105 case is completely isolated from the metal shrouded ports & PCB so a ground wire will not connect to the Cat7 shields.  It hasn't even got a high value earth lift resistor.  

The ports are interconnected for shields cross links,  so all the ethernet shields are interconnected

But a ground/earth wire will do nothing other than ground the case, semi useful (maybe)

This might explain why I could not really detect much, if any,  difference with a grounded case. 

What the situation is with other switches I don't know, but I would be reluctant to add a ground screw as I have done.  If it has a factory ground screw it might be a good idea to check continuity between it & the port shrouds so you know for sure - & not assuming -

Thanks Mike...

...More variables, this is driving me !

[Edit]  OK, I'll admit it I was already so it can't make me any worse.

Thanks Mike and Huge I'm pleased this discussion has evolved as it is.

Mike, on the Netgear switches, I use an alligator clip (ex a small jumper wire) clipped onto the metal spruced ports (the bridge between two unused ports). This was an attempt to ensure I grounded the signal reference. Similarly with the GS605.

i do completely understand your comment about being too mellow. I had been using piano sonata and Vivaldi string/mandolin as test pieces, along with a collection of diverse modern. My shift in presentation with the final gs605 ground on a Vivaldi mandolin piece was such I had to check I was A/B the same tracks!  I'm not convinced it is completely balanced yet, concerns about the initial 'grey/flat ' character of the GS605 remain.  However there is a whole lot more musical truth coming through, if not the whole truth yet. I'd like to try other components on the final leg in particular.

My suspects around the end-cause of changeable audible effects are two:

• the differential interface between the 1704 D/A chips and the I2V stage, which is running at 768khz oversampling rate and the application notes point to being very sensitive; and
• the resulting multi-pole filter stage.  The improvement of two 555ps on an NDS separates the digital side from the final analogue stage, the analogue stage being noise-susceptible. This is one good example of a $10k power separation producing benefits
• in the audio domain, -120dB (24bit res) below 2V is ~ 1 micro volt, and close to this we have 2 125mhz bandwidth data signalling, and they will remain completely separated, right?
• intuitively I suspect there may be interactions between noise and high roll-off filters producing audible artifacts, blaming 'jitter' as the sole cause of audible aberrations may be a simplification in the real world...

• BTW without wanting to get off-topic, I suspect a lot of the benefits of the 'pulse-amplitude modulator' DAC arise from less noise susceptibility in this critical area, compared to streaming DACs that aren't as fully optimised as the NDS.

On the benefits of CAT7 I suspect another benefit comes from well- balanced signal pairs and stable cable shell construction that helps preserve this balance, also more carefully constructed interfaces around the plugs that preserve impedance/balance (ie transfer vs reflectance) and reduce crosstalk?

We don't really know what's happening along the chain though I expect audio development engineers have an appreciation of these various mechanisms. I'm amazed one would expect someone to connect up a $5k Unitiserve and a $25k NDS with two $50 switches and a $500 NAS and expect everything to work perfectly and predictably?

My, there has been some activity on here whilst I have been away 

The one point I would say RFI doesn't automatically make a sound bright, depending on how it manifests itself it could dull an audio sound and rob detail, such as as if it's modulating a DAC clock and causing jitter.

Also the other variable with network communication using TCP, are the TCP parameters used between peers such as NAS/UPnP Server  and Network player ie NDX. TCP is not modified with regular switches operating at layer 2. This I have found quite noticeable, and I have rested on a Raspberry Pi running Debian Unix as the best sounding setup for UPnP Server.

Did a little experiment at my dealers a couple of years ago with different NASes / UPnP servers albeit with no Pi, and the difference on a 500 series setup was even more marked on than my classic series.

Simon

Brilliant ! Way above my head for the most part, but fascinating still. Thank you 40 below.

Couldn't agree more.

Among the differences, one thing I wonder, although the regulations regarding electronic devices may be the same, is the variation in mains-borne noise or RFI emission between different countries. Just to give an idea that may be completely coincidental, where I live, when I bought my MG B GT and went to the official control, the only change that was requested was to install new spark plug caps because the original ones would emit too much RFI. I'm still puzzled that such an oldtimer was considered so dangerous... If it's so stringent when a spark plug cap is at stake, I wonder what happens when it's a cell tower, not mentioning the tokamak (almost) down the road.

Hi Simon,

I read your many findings with a lot of interest. Drifting off-topic, but I'm wondering if you tried to optimize the settings in your IOS-based switch. Up to now, using the web GUI I just disabled PoE on the ports where I don't use it, but I wonder if you'd have any recommendation ? These switch are very capable, so maybe there might be some audible benefit in disabling functions that are not used, or maybe tuning here or there ?

Maurice

Maurice, the only thing I did was turn off spanning tree on the port connected to my NDX. This should have minimal impact but at least the spanning tree discovery PDUs are disabled, and when I need to power cycle my NDX (grrrrrr) the port comes up quickly on the switch.

Simon

Spanning tree - whenever I feel that I start to understand this stuff, something new and more incomprehensible comes along!

Ok, thank you Simon, I'll look into that.

Keep on trying Nigel. It's good for the brains, or so they say.

Maurice,

this is the IOS script I use (ignore vlan5 that is specific to my network setup for audio)

!

interface FastEthernet0/8
description NDX
switchport access vlan 5
spanning-tree portfast
!

Thank you. You have a separate VLAN for audio ? Why ?

Maurice, to reduce broadcast traffic down to a minimum... That is the OCD in me. But currently I have collapsed the vlans together as I am only using a consumer grade router, ie the Apple Airport Time Capsule.. And so unable to route between vlans.

Simon

I see. I should fire up a sniffer once. I just tried that a few days ago in order to find some ports left open, but it just managed to mess up the whole network and I had to reboot everything ! Don't ask, some free software for the Mac... I should try Wireshark instead.

Maurice, indeed Wireshark is the business, and often use it at work... When the pressure is on and one of my or my team's solutions is not quite working to plan its a godsend.

Of course a managed switch makes it easy to span a port for monitoring with Wireshark or equivalent to see exactly what is going on..