Importance of clocking

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

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

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.

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

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

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

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.

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

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.

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

@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

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.

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.

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.

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

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

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!