Importance of clocking

@lalitk Could you explain why the accuracy of the clock (which is defined by the long term stability in ppm) is as important? Genuine question.  For example the most accurate clock that I know of is cesium atomic clock which is approximately 1 -  3 part in 10^14. Is it relevant, does it matter for HiFi?

“I was merely pointing out that in our hobby the clock accuracy is not the most critical parameter”

@greg_f 

I believe accuracy, short-term stability and phase noise performance are equally important in a clock for optimal sound quality.  

I may not be arguing, but I sure as hell will not be buying any of his products.

Streamer onwards we want a clock, external or internal, which is very low noise and very accurate.

Up to the streamer we merely want a clock, external or internal, which is very low noise.

🙏

Thanks @greg_f - I agree!

@antigrunge2 In your discussions with @nigeltheflash you are both  referring to clock accuracy, I was merely pointing out that in our hobby the clock accuracy is not the most critical parameter. That's all.

@greg_f 

You are introducing the relative benefit of different types of clocks which has no direct relation to the topic discussed.

@greg_f Great post. Indeed, short vs long term stability is a key concern as dCS are particularly keen to point out.

This is in the bitstream domain though. Neither applies to the asynchronous ethernet domain. The streamer is where clocking, jitter, etc become real concerns impacting sound quality, not before.

🌻

@antigrunge2 I said "I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all"

You said "Congratulations on inventing a negative inverse tautology". I haven't. Please re-read. I choose my words very carefully.

You keep asserting that any reported sound quality improvements from an external clock must be due to its accuracy; I keeo asserting that it can't be, so we need to look elsewhere for the cause. I do NOT assert that an external clock cannot improve sound quality; I merely and persistently question your attribution of the effect to a cause.

Guys,

it all depends what is understood by the term 'clock accuracy'.

For example rubidium clocks have very poor short term stability, they jitter by design. This makes them totally unsuitable for a short term time base reference. Their big usage is due to their long term stability where the time has to be correct after a long time without synchronization (eg military applications). The long term frequency stability, the clock 'accuracy' is defined in ppm (part per million). The highest clock accuracy is not required for hifi applications.
An OCXO (or TCXO)  has a better short term stability (phase noise) but is doesn't have the accuracy of the rubidium. .
As in hifi the real long term stability isn't important, the better clock source is a very high quality OCXO or a TCXO.

My point is that the absolute accuracy of the clock is not as important as other aspects of it (phase noise, voltage stability, jitter, etc).

‘I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all.’

Congratulations on inventing a negative inverse tautology’

@cleeds It could, but I'm now unfollowing the thread so will only be notified if someone mentions me.

Peace, brother @lalitk!

I fully accept that an external clock might improve sound quality. I don’t accept that the reason for this has anything to do with the accuracy of the clock. That’s all.

Think about or investigate what a streamer does. Its job is to repackage lumps of data into (effectively) a continuous stream of data. It completely reformats it and the accuracy of the clock in the streamer is important to sound qualiity (I used to have a Mutec MC-3 reclocker after my streamer); ditto the importance of clock accuracy in the DAC (I continue to use an external clock here myself).

I am happy to stand by my assertion that there is no possible mechanism through which ethernet clock accuracy affects sound quality.

nigeltheflash

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

Wow. This could go on forever.

“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!

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.

@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.

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.

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

@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?

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

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.

@antigrunge2 You may indeed suggest that but I have read it before. While I congratulate John on an excellent piece of marketing, often referenced by people as if it has a peer-validated and objective status it does not, it contains many misunderstandings and factual inaccuracies.

Might I suggest you read this mythbuster in return?
https://www.reikiaudio.com/reiki-reflections/is-that-the-time-the-fallacy-of-ethernet-clock-accuracy

@nigeltheflash

may I suggest you read John Swenson‘s white paper on the Etherregen.,It is available on thhe uptoneaudio.com website. There is also an addendum on using external 10m clocks

@antigrunge2 ”It shows that the ethernet is a major source of DAC disturbances and some believe that clocking matters in that context.”

I’m not sure what you mean by “DAC disturbances” other than RFI noise affecting the analog(ue) part of the DAC. The streamer will have received ethernet packets/frames and unpacked these into a bitstream which it feeds to the DAC; the DAC itself doesn’t see anything ethernet. Except RFI noise which may have accompanied the digital signal created by the streamer of course.

If some people not only believe ethernet clocking can make a difference but experience that it does, we then need to move onto the mechanisms which might make this possible. Clock accuracy is not one of these, as explained earlier regarding its asynchronous nature. Something else may be at play and many of us would, I’m sure, be interested to understand what these mechanisms might be.

@lalitk 

Ok, got it. And yes, disconnecting outright doesn’t work; hence the offline feature in Sense

@antigrunge2 

Isolating Ethernet is not an option for me. My DAC is optimized to accept digital stream over Ethernet. I am streaming local and cloud based files from Aurender N30SA to Merging Technologies DAC.  

I believe severing Ethernet connection from your Innuos player should impact App connectivity to the player, right? 

@lalitk

Fully agreed. InnuOS does though offer a feature for playing local files while isolating the ethernet connection, the so called offline mode under Sense. It would be interesting to know whether disconnecting the ethernet cable from your Auralic equally improves the sound when playing local files.

About local files, couple of distinctions in my setup as to why local files sounds superior to those being streamed from Qobuz/Tidal:

1) No network noise and latency due to files being played from internal SSD storage of N30SA. 

2) 95% of stored files are digitized from analog tapes and direct DSD. 

IME, Tidal/Qobuz files are a mixed bag due to unknown provenance of files. There are some really stellar sounding files and then there are some that are simply unlistenable (to me). Not to mention, variables in our home network and equipments rendering the final sound. If one thing I learned with digital streaming is this, there is no streaming components at any price point out there that sounds optimal right out of the box without tweaking the home network. 

It shows that the ethernet is a major source of DAC disturbances and some believe that clocking matters in that context.

I will do, of course, and it will be fascinating.

I just don't know what it has to do with the earlier conversation about ethernet clocking!

Thanks, will try it

@nigeltheflash

You got a Pulse using Sense: pls try it out. Why else would InnuOS provide the feature

Just so I understand:

• you play a locally stored track in online mode
• you make no physical changes such as unplugging a cable
• you play the same locally stored track in offline mode
• and it sounds better?

If so, I can't begin to understand what the cause of this might be. Do you have a theory? Is it anything to do with clocking?🤔

@nigeltheflash

err:no, there is no streaming in offline mode and the sound improvement on local files is distinctly audible

Thanks @antigrunge2. Unfortunately changing to this mode still leaves the physical network connection in place if you stream AND play local files so the challenges and the possible solutions remain pertinent.

@nigeltheflash 

Apologies I was meaning to refer to the offline mode under system advanced settings

Thanks @antigrunge2. I had missed this update and am in process of installing.

However, I'm not sure I understand the "standalone" point you mention or what this has to do with clocking. Could you expand? Thanks and apologies

Nigel

@nigeltheflash 

This is why InnuOS has a standalone feature in Sense 2.6.3

@mikhailark On your point about local file playback, Roy Gregory was surprised to find a similar improvement with his Wadax server/streamer (see page 5 herehttps://gy8.eu/review/magnificently-minimalist/5/. I agree with his hypothesis that if there is less RFI going into a server/streamer via the ethernet connection then that will logically affect even local file playback.

Re RFI, I mean both. Yes a switch generates its own RFI but steps can be taken to minimise that generation and the massive reduction a good switch makes to reducing incoming and therefore "net" RFI is clearly audible.

Disclosure: as per my profile, I design and build switches for audio purposes so I have spent loads of time working out what can/does and can’t/doesn’t make a difference to sound quality.

My key point in contributing to this thread is not to argue the merits of various RFI-mitigating approaches (that has been and can be discussed elsewhere). Here I simply wanted to point out the clear difference between clocking in the asynchronous ethernet domain and clocking in the synchronous bitstream domain.

@antigrunge2 Re Innuos, you’d have to ask them but I suggest you first carefully read what they say on their website about the contribution of the clock to the performance of the PhoenixNET. I suspect it’s economies of scale: they needed a clock of some sort (all switches do) and they already have one which they know is both accurate and quiet. Why source a cheaper clock which may also be noisier in RFI terms?

You asked about my equipment. I use Cat 6A shielded cable into a Reiki Audio SuperSwitch into Innuos Pulse Mini with a Zen Mini MkIII power supply which has been moderately pimped to improve its performance. I have used a short (0.5m) Cat 6 unshielded from Pulse to dCS Puccini DAC (with external U-Clock) but am enjoying other short cables here so will swap the Cat 6 out.

@antigrunge2 

Well, some reviews claim "The Innuos PhoenixNET will also improve your music playback from the files on the music server itself. Even though that music isn’t being streamed through the PhoenixNET. You heard that right."

Well.... something not even connected somehow improves the sound. OK.

Some digging around revealed that, for example, Ethernet does not do error correction. it does discard corrupt frames though. and TCP will retransmit lost packets. So the switch may be simply buffering frames and then transmitting in sequence on cable with fewer dropped packets. How does it affect the sound? Depends on quality of the streamer. 

@nigeltheflash - Do you mean RFI on the twisted pair or in the space around the unit? Simple shielding or or galvanic isolation would drastically reduce RFI. Not sure about necessity of switch for that purpose since it runs its own CPU and hence makes its own RFI. 

@nigeltheflash 

I stand by what I hear and am not impressed: why would InnuOS include an expensive Ocxo clock if it has no benefit? And reclocking the Etherregen is very audible. so what is your equipment and reference base for making all your statements?

@antigrunge2 You said "I don‘t understand InnuOS‘ selling separate reclockers for USB and Ethernet without synchronising Ethernet input, DAC conversion and USB output."

The PhoenixNet operates purely in the ethernet domain to kill RFI noise, it is not there to improve signal timing accuracy so decribing it as a reclocker isn't really accurate (this implies the improvement in sound quality which PhoenixNet users report is down to more accurate clocking and it's not).

You can't synchronise asynchronous (ethernet) and synchronous (DAC); it doesn't make sense.

Network switches used to improve sound quality (rather than just giving extra ports as originally intended) do so by massively reducing the amount of RFI reaching the streamer. I guess it will also filter out other traffic in the process, but it’s the RFI from other connected devices rather than some sort of digital crosstalk.

An unmanaged switch will do just as good a job of filtering RFI as a managed one, as the management bit is nothing to do with RFI.

@antigrunge2 I assume you mean Phoenix NET network switch. I can theoretically imagine that streamer has underpowered CPU and low performance network stack and hardware so an extra switch before it helps.

The network switch may be set up to filter out other traffic (like your kid playing Warcraft) so only audio related traffic reaches the streamer. It is possible that streamer CPU is low performance in order to avoid spinning fans and cooling issues. 
 

You count obtain your own network switch for like $100, but setting it up properly may be a challenge unless you are proficient in IT.

@antigrunge2 

Let‘s just say that my ears and reputable designers like Innuos, Esoteric et al disagree with you

Dont simply trust “designers”. Companies want your money and will happily sell whatever for a profit. Always verify their claims. I have seen big, imposing chassis from a very reputable company which should stay unnamed, that was literally empty inside with puny power supply and 2x2” PCB board. I costed $$$$ and got rave reviews.

I can only reiterate what I hear: Etherregen with and without external clock are miles apart. So something happens ahead of the streamer that is affected by the clock. Interestingly John Swenson acknowledge the beneficial effect in his white paper, too.

It is vitally important in such discussions that we avoid conflating/confusing the ethernet domain (up to the input side of a streamer) with the bitstream domain (output side of streamer onwards).

@erik_squires is spot on here. The ethernet domain is asynchronous and based on packets/frames being distributed, with error-checking and resend built in to the 7-layer OSI protocols. It stops at the streamer where these packets/frames are converted to a continuous bitstream. At this point, streamer output side onwards, clock accuracy is important to sound quality but there is no mechanism for clock accuracy in the ethernet domain to have any effect on sound quality.

An ethernet clock may be quieter of course, and this could conceivably impact SQ, but I’ve never heard any manufacturer argue that theirs is.

Innuos are careful in their PhoenixNet blurb NOT to assert that the clock they use in it, which is the same as in the Statement I believe, has the same effect on sound quality. They talk instead about the proximity of the clock to processor avoiding the risk of data losses which might conceivably occur with an external clock (though personally I struggle to see this).

Hope this helps clarify.

Would love 'simple,' but complex has reaped sonic benefits!