I strongly suspect that option 3 is the likely effect at work here where there is a beneficial impact on sound.
1 Like
Option 4 is incorrect. In purely digital terms - and you probably know this as you appear to be network-savvy - it makes no difference at all where you place a switch in a network. In non-technical terms, it just takes data packets in through one of its ports, asks which other ports are connected to devices looking for data, transfers it, checks it got there, resends if it didn’t - and repeat. Data in, data out.
In sound quality terms, it’s not only the sequence of your network nodes that matters, it’s the physical distance between them; well, specifically between any switch deployed for audio optimisation purposes (rather than as a port replicator) and a streamer. This distance should be as short as possible because the switch is here to minimise the amount of upstream RFI noise accompanying the data which is forwarded downstream to the streamer.
From a tech (digital) network engineering perspective this makes no sense as the data reaching the streamer is identical; but from an audio perspective it’s vital that the switch-to-streamer leg is short as this gives less opportunity for environmental RFI to sneak in a the last leg ie into the cable connecting the switch to the streamer.
Those with Melco model familiarity will need to explain how this applies to any specific model, but I thought it was important to clarify that your hypothesis 4 is already proved false before you start! Your ears will prove this if you position a switch just before your streamer and connect it first via a 10m cable and then by a 50cm cable.
Hope this helps.
PS, I use a Synology NAS connected to my router and the router connects via 8m of Cat6A to a switch just behind my streamer and rest of hifi system.
2 Likes
Thanks agreed and yes thats close to what I do, I have a 48 port Ubiquiti switch in my office which is wired with 10-15m run to ubiquiti 8 port enterprise pro under the stairs where the broadband comes in. Synology NAS and hp desktop pro in the office house my roon server and music files. 3 Ubiquiti wifi APs scattered around the house are ethernet connected.
I have a second dedicated 8 port Ubiquiti switch in the hifi room connected via a 6m run and the linn ds is connected to this switch via a dedicated Ubiquiti poe powered flex mini. This combination sounded better than an old netgear switch I had been using for my last leg. I was delighted to get the last non unifi switch out of the network. It makes managing the setup so much easier when it is all unifi gear.
Edit - i also did try to put a 6m ethernet cable as the last leg and it sounded worse. Picking up rfi noise I assumed.
Edit 2 - I did put a liberal scattering of rfi ferris chokes on the network - not the last leg, worrying particularly about the APs and the long runs. I hear mixed views on their impact on packet loss across the network but Simon had previously indicated they should be fine. If it was a commercial network deployment I understand why they would be frowned upon.
1 Like
When you’ve done, how about adding a Melco D100 CD ripper, and exploring the reason why rips done with it apparently sound better than rips on other devices, even when both are confirmed by AccurateRip to have identical music data?
1 Like
Just to add once the linn kdsm arrives I will be testing ethernet v optical v wifi as the last leg. If wifi works at least equally well, thats likely the direction I will prefer to get rid of all these network interference issues.
1 Like
I thought we were done with this. It’s explained perfectly well on the other thread - no mystery.
One thing at a time and lets perhaps keep this thread clear of that discussion 
I don’t recall seeing any explanation of the cause, in that thread - there were plausible suggestions but they were only that, nothing examining whether any indeed are true of what is happening in the case of D100 rips played on Melco. t I will go back and look at the latest contributions, any discussion to continue there.
Apologies if I misunderstand but how long is the cable from switch to Linn DS?
Look at @Simon-in-Suffolk’s explanation.
In essence one is not listening to the rip. One is listening to a file construct containing the rip. This will be different acording to what ripper is used. Deconstructing this file construct will result in different errors/noise during playback. It is not a perfect process. So even though the actual audio data may be identical, in the real world the resuts heard will not necessarily be.
About 2m if I recall but aill check later, Its standard spec cat 6 ftp cable I picked up years ago. Every time I try to swap it out I seem to hear more distortion so it persists! I have lots of flexibility on how to setup the last leg. The switch is powered via one of my three dedicated spurs. I have that positioned between he speakers whilst the hifi is to the side. I can always move this around as part of my wifi v ethernet v optical investigations - in particular never tested a very short last leg run with anything other than amazon basics cable.
1 Like
Foiled Twisted Pair is great anywhere else in your network but the foils can be grounded to both metal RJ45’s: a multimeter set to ohms will quickly tell you if you have circuit continuity from one RJ45 to the other. If you do, this can undo much of the good work a (any) switch does in mitigating RFI noise because the noise travels down the shield. Cat8 specs state the overall shield must be grounded at both plugs so this to be avoided in this specific use case too. If you do try a 0.5m cable here, perhaps make it Cat 6 UTP?
Good luck!
1 Like
Will do. Thanks! Happy to test out cables here so long as they stay in spec.
Edit I’ll also double check if the cable is FTP or UTP - i was going from memory from years ago but it will likely printed on the cable.
1 Like
I’m also up for some actual measurements of cables. I’m not an electrical engineer and have limited knowledge here but a friend who is (and used to be a philips engineer on cd drives) recommended a spectrum analyzer to really find out what is going on. Happy with a little guidance to explore that avenue for fun.
1 Like
I’ve slightly amended to clarify my last post here, I have responded fully in the other thread, which is where the OP and I have suggested it happen.
1 Like
If you have the facilities to measure conducted and/or radiated RFI noise then you have a pretty advanced setup! This is the only thing you could possibly measure on a network cable which would have relevance to audio. Audio signals are nowhere near testing the limits of data carrying capacity of an ethernet cable so the data will arrive in good order regardless of any measure you might make of bandwidth.
A spectrum analzer is red herring in the ethernet domain. Sure, tmight be fun but it won’t tell you anything remotely useful. Measurement of capacitance/inductance/resistance etc might be interesting post-streamer but the ethernet world is different. The data will reach the streamer in identical fashion whatever cable you use and how long it is; it’s the side salad of noise which accompanies it which is the only variable we can and should control in the pre-streamer world.
2 Likes
Good news. I was mistaken. Never rely on memory. UTP. Kind of explains why it hasn’t been dislodged yet 
1 Like
When you see “Hypothesis” in a hifi forum.
Obviously more concerned with the process rather than the results.
Like more concerned with the hifi rather than the music.
The recommendation of asking a dealer to lend the items will save so much time and effort.
1 Like
Yes the plan is to ask a dealer to lend the parts. The hypothesis part is to decide what to test and where. The melco can go in several different places in my network. And I can do various a/b comparisons. Hope that helps.
That does seem quite a challenge.
I always try to remind myself to make things not as complicated as they could be. 
1 Like