Importance of clocking


There is a lot of talk that external clocks because of the distance to the processor don‘t work. This is the opposite of my experience. While I had used an external Antelope rubidium clock,on my Etherregen and Zodiac Platinum Dac, I have now added a Lhy Audio UIP clocked by the same Antelope Clock to reclock the USB stream emanating from the InnuOS Zenith MkIII. The resultant increase in soundstage depth, attack an decay and overall transparency isn‘t subtle. While there seems to be lots of focus on cables, accurate clocking throughout the chain seems still deemed unnecessary. I don‘t understand InnuOS‘ selling separate reclockers for USB and Ethernet without synchronising Ethernet input, DAC conversion and USB output.

antigrunge2

Scroll down. Precision is about proximity not about reclocking. This proximity "avoids data losses" which are hardly likely to happen anyway (when did you last experience data losses on your internet connection?).

"02.

Increase Clocking Precision and Stability

Using the same 3ppb 25MHz OCXO oscillator as used in the Statement, individually powered by its own linear power supply and connected directly to the network switch chip, avoiding precision losses from using external master clocks."

Each of us is free to believe what we want but facts are facts. Innuos play it safe here. dCS are on record as saying ethernet clock accuracy can't make a difference to sound quality. However the broader industry is rife with misunderstandings of this domain, almost always arising from inappropriate extrapolation from the post-streamer domain (where jitter is a real thing affecting sound quality and clock accuracy is king) to the pre-streamer domain where it is not.

Google "OSI Model" and focus in on the Physical Layer which requires clocking. The reflect on how any timing information might be relevant to sound quality, given that the streamer will apply its own timing when it converts the packets to a bitstream.

@nigeltheflash 

I am sorry but you are being argumentative: on your logic the clock in the device is superfluous yet InnuOS expressly extoll its importance and the attached review of the device amply speaks to its sonic benefits. The same applies to Uptone‘s Etherregen so I am frankly not interested in further reiterations of your postulate. Over and out.

As you know, it takes two to argue. I'm merely reasserting my position every time you reassert yours.

On my logic, the accuracy of the clock in the ethernet domain is irrelevant to sound quality. I absolutely do not assert that the clock is superfluous, you're putting words in my mouth. A switch needs a clock to function.

You have yet to offer any explanation of why/how ethernet clock accuracy could possibly affect sound quality. Noise generated by the clock could differentiate one clock from another.

Likewise, over and out.

 

 

“On my logic, the accuracy of the clock in the ethernet domain is irrelevant to sound quality”

@nigeltheflash

Acording to your logic, if accuracy of the clock in the Ethernet domain is irrelevant then why some of these switch manufacturers (I can name a few) advertising the importance of clock in a switch. Excerpts from Reiki Audio blog you linked in your post.

“Reiki Audio SuperSwitches employ an enterprise standard 25MHz clock which delivers the highest possible audio performance.”

The clock signal in a digital circuit serves as a timing reference. The clock helps coordinate when data should be read or written, ensuring proper sequencing and functionality of the circuit. If a switch needs a clock to function then by all means a cheap or subpar clock can easily degrade the audio. No one here is arguing over IP…I believe the core of the argument here is why OP heard audible improvement by connecting a highly accurate external clock which is obviously superior than the one included inside the EtherREGEN.

IME, anytime you can improve the accuracy of clock, you’re likely to hear audible improvements. The magnitude of these improvements are clearly system dependent and one’s listening skills. The proof is in listening and not waging an argument “oh that’s simply not possible given the standards sets by TCP/IP”.

Peace!

nigeltheflash

... it takes two to argue. I'm merely reasserting my position every time you reassert yours ...

Wow. This could go on forever.