Ethernet Clocking

Thanks @cindyment the kind words.   I would not dispute your observations about USB ;-). You are probably right.

i learned one thing out of that thread, which is a twist on what I knew already: one can only share their experiences and knowledge with others.   What the do with it is up to them.  
I can’t stop folks from buying Ethernet reclocker, a fine asynchronous error-correcting protocol with no clock, neither should I.   I’m quite sure we will make warp drives work before we can explain what audiophile Ethernet switches and cables actually Do.  
In the mean time, I’ll continue to spend my money on DACs, preamps, amps, speakers, subs and room improvements,,other will do what they wanna do.
The one thing that bothers me is that there are equipment vendors that peddle bizarre stuff. If you’re a vendor that knows enough to build one of of top ten DACs on the planet, you know that external clocks are pointless.   I’m talking to you DCS.   Or you can explain to us why it’s not.  Not in terms of blah blah blah, but how it helps to clock the right bits in the Dac.    You won’t hear that, cause it does not. And that bothers me.   

I’m new here. 40 years audiophile. 30 years designing software and hardware for switches, routers, high performance wifi access points.  
Open minded guy, I think.  I have iso pucks everywhere, nice cables, power regeneration and what have you…. Clearly not Amir’s best buddy.  I believe just about anything can affect sound.   
In the process of building networking gear that sold for billions of dollars (if you get out of the house, you have used gear I had something to do with, it’s a small world), I learned a thing or two.   And yet, I do not understand anything about audiophile Ethernet switches and cables.   The issue here is that I can always at least find some theories  on why this or why that can be possible.   I am completely empty handed, either reading the specs of those devices or putting to work my fertile imagination.  
Our community has been fed so much crap about the wonders of digital music since the first CD, some of those promises are just starting to come true.  We were blessed with SPDIF, USB, TOSLINK and other atrocities.  None of this stuff has a combination of CRC, forward error connection, retransmission or even any sort of link monitoring.   I shell out decent cash on all those connections cables  because the whole link layer protocol is just a sac of crap.   I guess even the high end audio industry is not found on fixing this, it is a product offerings bonanza.  
Now enters Ethernet and TCP/IP. Different ball game.  I would not blame anyone to be skeptic, see previous point.    There’s no point starting an enumeration here, point is that I can find a thousand reasons why there’s zero chances this networking stuff will change the sound. 
I’m going to go one notch farther.  I have a brillant idea for a product design that can take all the voodoo out of it.  It would be a pain to do this, but we could build a system that would compute the SHA-1 digest of all the bits fed to a DAC chip and report whether piece was authentic to the source file.   That would be a really fun project.    Or it could be done on SPDIF and USB too.   I would love to see this done.  That would not completely close debates, my bit is sweater than your bit would go on, but that would do it for me.  
In the mean time, I will continue to choose Ethernet cables based on color :-0.  Oh one last detail.  Last time I checked, 1000base T Ethernet does not have a clock.   So there is that, it’s a whole new world.  

clıcking ? @cakyol 

Except @lmcmalo cant help but chip in.    Let’s pass the point where some vendor has a RE-clocking product for a protocol without a clock :-0

Ethernet phy layer is an asynchronous.  Very roughly it works like this. Very roughly, it’s complicated in practice.  The line goes flat, there’s a gap between packets.  Then comes a fixed start sequence, the receiver locks on it and then runs its own clock starting from that point on the negotiated speed.  It works fine because it’s very brief.   The clock has to be in sync for that  1 packet.   Because there’s CRC, errors can be detected.   Phy errors are uncommon in normal situations   And no one cares, the missing packets get retransmitted by TCP..

 
This isn’t voodoo, but I must have wasted months of my life on « SPF modules ».   Those are Ethernet phy modules that can be swapped out in fancy switches instead of RJ-45.    Lots of compatibility problems.   The beauty is that mostly they work or they don’t…   Sometimes it’s in between and then some software detects the problem.   

@richtruss I really wish I could, UK  is a long way away from California, I'd actually make a bit detour to listen to that.   But i am taking your word for it. I will continue to assume that it's possible and be on the look out for some explanation.   This is part of what makes this fun.

Look, there are thing not completely explained going on in my own system.   Due to the system evolution, i have 3 methods to play files on my Roon Nucleus (that's another thing, when you do this for a living, messing around with DIY NUC is less appealing).  It can go this way, all with Roon:

Nucleus - Ethernet - Naim XD5 XS2 - Bricasti M3.

Nucleus - Ethernet - Bricasti M3 (optional network interface)

Nucleus - USB - Bricasti M3

Those 3 methods sound very, very similar.    As a reference, not as obvious as changing the M3 filter (Linear/Minimum phase).  I'm still trying to fully qualify this.   That's were this idea of being able to validate the bit stream the DAC gets would be awesome.   Since I have converted everything to Roon, I'd like to get the Naim off the stack, but at this point my perception is that this is the path that sounds best.   IMO, the path that has the best chances of presenting the right bits to the DAC would be be second option, no USB or SPDIF involved.   The quest continues.

@antigrunge2 Can't argue with DCS products.   John is a sales guy, keep that in mind.  This quote is out of context.    An external clock is useful 'maybe' to synchronize multiple boxes which i am not aware of any needs for doing so in HiFi.   There are difficulties with that too.

Again, clocking is not complicated, with the caveat that I am not designing DACs at DCS ;-).  One can go to Renesas or Analog Device and buy a a chip of a few  dollars that produces a clock with with jitter in the range of a few hundreds femto second.   This is another audio mystery to me.   I have no idea what is going on in a DCS clock box.   The engineer in me says that a 2$ chip right by the DAC is better/cheaper solution if the goal is to present the original bits to the DAC, but what do i know?  

I'd try a DCS DAC any day, dont get me wrong (Although i'd buy a Tambaqui in the spot if it would come to used market), but i really, really do not like the external Clock business.   Same a the Networking stuff, there is no engineering explanation for it.  The gobbledygook from John Quick isn't it.   I can speak gobbledygook but i prefer English.

This has zero applicability to Ethernet.    THERE IS NO CLOCK GOING ON Ethernet CABLES.   I dont know how else to say that.   1000baseT Ethernet has 8 wires, in 4 twisted pair, and they all carry data using the 4 pairs.   Every frame, carrying a data packet (typically less than 1500 bytes) starts with a fixed 8 bytes of data that the receiver uses to synchronize its clock to decode the payload.   Ethernet 're-clocker' aren't more of a thing than dry water, sorry, there has to be a line somewhere.  USB ire-clocker is a different matter, I would not be caught dead buying one, that's a different conversation, but at least there is something to talk about there (there is an actual clock ;-)). 

@laltik I do respect your experience but his journey is not for me :-)

maybe if one day I can grasp one reason why those things work, I will.

@antigrunge2 im not a network engineer.  You don’t seem to understand the difference.    I design and build networking equipment.   The gear I work on provides networking to some of the largest retailers, colleges, etc in the US and worldwide.  My gear provides wired and wireless access to 3 of google, Facebook, apple, Amazon ;-). Have you been to Starbucks or McDonald?  :-)

You are welcome to remain unimpressed and you should :-).  Based on his white paper, I don’t think I’d hire John.   Perhaps a bit of critical thinking on what a fellow in company of 2 says would go a long way as well.

i have utmost respect for dcs company and products.  But it’s not because it’s audio that everything is suddenly voodoo.   I have access like you do if you and acquire knowledge to read them, to components specs.   There is zero, I mean zero, need for an external clock device.   A 1x1 inch square and less than 10$ makes a clock with 200-300 femto second precision clock that’s at least 1000x better than what anyone can hear.   And fact, putting a clock in another box far away can only screw it up more.   Who knows, maybe it sounds better this way?  

long story short.   I am very respectful of of what folks say they hear.  Analog, Everything goes.   Fuses, 10K cables, I won’t argue.   Amir will ;-).   The idea that bits aren’t bits is insane.   If you don’t believe that, you need to stop surfing the web, put your money in the bank, use a GPS, a computer, digital photography, mobile devices, drive a car made the last 30 years, if a bit isn’t a bit, none of those things work.  See my first post on this thread.   Bits aren’t bits comes about when you put bits through bad protocols like SPDIF and USB and the delicate operation of a DAC.  In the networking realm, a bit is a bit.  

@lalitk I guess I should have said ‘almost’.  I just bought a $400 usb cable.   Maybe I’ll make my way to Ethernet some day.