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

@nigeltheflash

while you are entitled to your views the fact remains that reclocking the Etherregen has an easily demonstrable effect. John Swenson in opposition to you acknowledges that. And Reiki Audio‘s point that manufacturers include expensive Ocxo clocks in switches ‘because they have easy access to them’ defeats normal commercial logic.

It may well do. I merely assert that this cannot be anything to do with the greater accuracy of the external clock.

Reread what Innuos say about the clock in the PhoenixNet. They are careful not to attribute anything to their clock’s accuracy in this context. They know what they are doing.

If you work in a commercial capacity yourself then you will appreciate that economies of scale may indeed make it straightforward for a company to use a clock they know to be quiet rather than to invest precious R&D time and money seeking to source a cheaper clock that is similarly quiet.

You clearly believe ethernet clock accuracy has an impact on sound quality. If you could explain how, in your own words, the timing of an asynchronous error-correcting buffered data stream which is transformed into a completely different format by a streamer can have any effect at all on sound quality then we may have a basis for further dialogue. If not then I’m out, content that I have made my point clearly.

Thanks.

@nigeltheflash 

From the InnuOS website on Phoenix Net: ‘The PhoenixNET is the realization of Innuos' philosophy of simplicity and signal purity applied to the network switch. Having started with improvements to the Ethernet ports' clock on our flagship Statement, Innuos has now brought the concept to a network switch design that focuses exclusively on audio use for musical details that stand out, a blacker background, better instrument separation and realism.’

 

Sounds very much like InnuOS thinks the clock on the Ethernet port matters, doesn’t it?

And here is the Audiobeatnik, one of audio’s most respected reviewers. In particular take note of InnuOS’s statement on clocking:

 

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.