Jitter solution

[mike7877]

This might be insanely simple... but could you not use one clock to run 3 in parallel, and hook those three clocks to a custom gate that needs any 2 of the 3, or 3/3 clocks to agree? (and in the off chance they all disagree, reference the clock that drives the clocks)?

Why can't this be the solution?

 

[charlielaub]

Still beating the old jitter horse? It's been quite dead for awhile now...

 

[solderdude]

This might be insanely simple... but could you not use one clock to run 3 in parallel, and hook those three clocks to a custom gate that needs any 2 of the 3, or 3/3 clocks to agree? (and in the off chance they all disagree, reference the clock that drives the clocks)?

Why can't this be the solution?

Because clocks are free running and would interfere with each other.
And when you use one clock as a master to sync 3 other clocks there is no benefit in that either as they will simply slave the first clock.
Why would that reduce jitter of the first clock and why would one want to do this ?
Why would clock jitter be reduced ?

 

[voodooless]

A solution in search for a problem

 

[mike7877]

Because clocks are free running and would interfere with each other.
And when you use one clock as a master to sync 3 other clocks there is no benefit in that either as they will simply slave the first clock.
Why would that reduce jitter of the first clock and why would one want to do this ?
Why would clock jitter be reduced ?

OK, put another way, the master clock is a lower frequency, the 3 clocks are higher frequency. The three clocks run 1000x faster than the master clock. Could total jitter not be eliminated by comparing all 3 and when the 2 of 3 or 3 of 3 match and don't jive with the master clock, the master is ignored because that's its jitter?

Maybe I don't have the exact solution, but there has to be a way to reduce error by compounding

 

[Blumlein 88]

Please just stop.

Jitter is not an audible problem. Nor is it even close to being a problem.

 

[DonH56]

No. There is no practical way to implement the comparison without adding additional jitter, given the bandwidth needed, hysteresis, and jitter added by the comparator itself. You cannot eliminate total jitter anyway because some comes from the master clock itself. Modern circuits reduce jitter to far below audibility using conventional, long-proven approaches such as reclocking, buffering, and local clock generation with low-noise PLL circuits. Additional circuitry just increases jitter. You cannot reduce the mud in a stream by splitting it into three parts and adding a little more mud.

 

[MRC01]

One thing I discovered as I read more about this topic is that the solutions already implemented in modern well designed circuits are well devised and highly effective. It's a solved problem, new creative approaches are not only not needed, they wouldn't work as well as what we already have.

That's not to say jitter and more generally digital data sync is a non-issue - especially with S/PDIF where the receiver must constantly adjust its rate to adapt to the transmitter. In short, S/PDIF is a "push" protocol, as opposed to USB which is a "pull" protocol that obviates the need for one device to adapt its clock to another. Even recently I've encountered devices where S/PDIF jitter is so bad it is more than just jitter, but complete loss of data sync with audible scratchy noise during frequency sweeps indicating something is wrong. Here's an actual distortion / frequency graph:

This particular device was the SMSL SU-6 which had a setting called "dP-DLL" which adjusts how far it will adjust its own clock rate to adapt to the incoming rate of an S/PDIF digital signal. Once I changed that setting, I got this:

And even that level of distortion is limited by my measuring device, a Tascam DA-3000 recorder, which is nowhere near as clean as Amir's Audio Precision analyzer. This tells me that jitter is a non-issue with well engineered devices. As long as devices achieve proper data sync, jitter will be well below audible levels. And you can see this in Amir's DAC reviews as he publishes jitter over S/PDIF (coax & toslink) and USB.

 

[RayDunzl]

Jitter, in another thread:

Does a jittery stream affect quality if reclocked?

But it can only work effectively if #2 properly works. Clearly in your case, it does not. It's not about being effective. It's about being possible. And about how the related jitter will affect the stream before the reclocking, as shown on my examples.

www.audiosciencereview.com

Sidebands in the air in my room (jitter?) from the ceiling fan:

Close in jitter?

Here are the jitter results for the Benchmark DAC2 done by Stereophile. That is about as good as it gets. 16 bit and 24 bit. The spikes in the 16 bit signal are supposed to be there. They should be at certain exact frequencies and levels with nothing else. The result below is essentially...

www.audiosciencereview.com

 

[JustJones]

 

[Philbo King]

This might be insanely simple... but could you not use one clock to run 3 in parallel, and hook those three clocks to a custom gate that needs any 2 of the 3, or 3/3 clocks to agree? (and in the off chance they all disagree, reference the clock that drives the clocks)?

Why can't this be the solution?

Maybe a rubidium atomic clock? Seems overkill...

 

[tmtomh]

Because clocks are free running and would interfere with each other.
And when you use one clock as a master to sync 3 other clocks there is no benefit in that either as they will simply slave the first clock.
Why would that reduce jitter of the first clock and why would one want to do this ?
Why would clock jitter be reduced ?

Yep.

Turtles all the way down - Wikipedia

en.wikipedia.org

 

[Keith_W]

Maybe a rubidium atomic clock? Seems overkill...

Atomic clocks do not reduce jitter. What they are good for is long term stability, e.g. if you have a clock that runs for years, they are vastly superior to any other clock technology because they do not drift as much. For audio applications they are almost useless. I researched this many years ago because I was misguided and I thought that the purpose of the clock input on my Merging DAC was to improve sound quality. Turns out that the purpose of the clock input is to sync multiple digital devices and it would do nothing to improve the sound of a single DAC. I was fortunate that I did not actually spend any money.

Having said that, I am a lover of wildly inaccurate clocks. I have a few mechanical watches and a mechanical cuckoo clock, not one of those awful digital monstrosities. Turns out that you can buy the mechanism for cuckoo clocks and DIY your own case, so I might go do that

 

[sam_adams]

You cannot reduce the mud in a stream by splitting it into three parts and adding a little more mud.

Absolutely great description. Thanks, Don.

 

[solderdude]

OK, put another way, the master clock is a lower frequency, the 3 clocks are higher frequency. The three clocks run 1000x faster than the master clock. Could total jitter not be eliminated by comparing all 3 and when the 2 of 3 or 3 of 3 match and don't jive with the master clock, the master is ignored because that's its jitter?

Maybe I don't have the exact solution, but there has to be a way to reduce error by compounding

Also no.

You just create 3 free running clocks that every are synchronized about every 1000 pulses.
A: You cannot create (affordable) clocks that all run at the exact same frequency, let alone share the same phase.
B: When you start comparing and there will always be at least phase differences which one do you pick and will that be the same the next time.
C: Jitter of the slower clock will determine the jitter + at least the one that it picked + at least the 'switch' which passes 1 or the clocks (2 others will always be at least out of phase after 999 pulses which is the decision point.
D: after the decision is made the clocks will sync again and will give a discontinuity in the chosen 'best' clock, resulting in you guessed it... even more jitter every 1000 pulses of the slower clock.
E: The decision circuit (which needs to act fast) will have 3 inputs that will not react at the exact same voltage so will add jitter.

One thing you are correct about.... you don't have the exact solution.
Consider that after the moment 'jitter' has been said to be an issue (decades ago) smart people have tried to come up with solutions and created fixes so that these days jitter (there are many kinds of jitter) is reduced to inaudible levels.

It seems like you try to re-invent the (fly)wheel for clock generation. This while most of the jitter generated in devices is not a clock stability issue (drift and stability is) because the jitter is usually caused by switching components in the circuitry around the clock and connections.

 

[Hayabusa]

in theory if you would have multiple LOCKED clocks in parallel and each jitter would be purely random and you would add them together analog it would reduce the jitter at the expense of rise fall times. Also if you would do majority voting there is higher chance the resulting edge is closer to the correct phase.

 

[solderdude]

Again.... jitter would then still be determined by the clock everything is locked to.
I see no benefits, just a lot of complexity that still has drift and stability of the master clock and the jitter of the 3 PLL's that are then averaged just a little.
I have not seen clock circuits employing this strategy.

Jitter in practice is caused by the way digital signals are transported and steepness of the many gates in the total circuit etc.

 

[DonH56]

Maybe a rubidium atomic clock? Seems overkill...

Atomic clocks are great for long-term stability but their jitter is usually (very) high (poor). At least the ones I have worked with (maybe half a dozen) had high noise and jitter; we used conventional crystals and related resonators for the lowest phase noise (jitter). Different circuits for different applications.

Edit: @Keith_W beat me to it!

 

[voodooless]

There are two things at play here: frequency accuracy and frequency stability. Only the last one is really relevant. That two clocks deviate in speed by let’s say 1ppm is irrelevant. You won’t hear the difference. But the jitter part is the frequency stability: how much does the clock deviate its frequency over time while maintaining a stable average frequency.

For the 3-clock scheme to even resemble a chance of working, you’ll need clocks with the exact same frequency accuracy. That’s is basically impossible to make. So, as soon as the clocks deviate, your lost.

 

[BDWoody]

Maybe I don't have the exact solution, but there has to be a way to reduce error by compounding

What is making you believe it is a problem that needs more attention?

Here is a site where you can listen to varied levels of jitter:

what does jitter ACTUALLY sound like?

In a previous post we had an encounter with jitter in audio. The talk about jitter is hard to miss these days. There are plenty of products on the mar...

www.sereneaudio.com

Jitter has to be pretty extreme before it is going to be an audible problem.