Jitter solution

[mike7877]

There are a lot of threads here with the same subject.

Yeah, but they're all a little different. I'm glad I know it won't work and why

 

[voodooless]

Specsmanship?

No, it’s a pro-audio device, and therefor, it’s expected to be bulletproof with even the most crappy digital sources. It will also lock much faster than traditional clock recovery circuits, which can also beneficial to pro audio solutions.

None of this has anything to do with a few ns better clock.

 

[solderdude]

The comparator would be a counter, not a clock

What would a counter do other than count pulses ?
When clocks are synchronized in a 400kHz rate all 3 clocks will have the same count and what would one do with a pulse counter ?

edit: plus what I put in post 23.

A counter is immune to jitter. It just counts periods.

It's just an idea... I do expect to be wrong or for there to be a reason why it's not implemented.

Ideas are great. There is no practical benefit with your proposed method. In fact more likely the opposite. Switching between clocks is bound to have timing issues which you plan to avoid.

 

[sergeauckland]

I don't think that audiophiles are the primary consumers of portable digital audio interfaces lol. But yeah, I'd say they do it to say they made an improvement to something so that they're not selling the same product for 10 years.
I meant more in general why so often do people question improving something just because it's "good enough". If everyone just said "good enough" all the time the world wouldn't be nearly as advanced as it is now

It might be better in that we weren't being constantly persuaded to buy new stuff to replace perfectly good old stuff. There would be a lot less landfill and plastic in the seas if we consumed a lot less and kept a lot more.

S.

 

[fpitas]

I meant more in general why so often do people question improving something just because it's "good enough". If everyone just said "good enough" all the time the world wouldn't be nearly as advanced as it is now

I agree. But you have to solve an actual problem. Anyone can just putter around and change things.

 

[sergeauckland]

I agree. But you have to solve an actual problem. Anyone can just putter around and change things.

This, I think, is the crux of the issue. What problem is being solved by the technical improvement? If none, then the improvement is just an intellectual exercise for the designers and a hook for the marketing people.

I accept that a manufacturer that doesn't update their products for 10 years is unlikely to be around for another 10 years, but nevertheless, the relentless chasing after imperceptible improvements is just like the fashion industry - this year's colour, this year's skirt length or lapel width. Nothing of any substance. Just keeping people employed and society on the treadmill of consuming. Aldous Huxley said it in 1931 in Brave New World.

S.

 

[fpitas]

If none, then the improvement is just an intellectual exercise for the designers and a hook for the marketing people.

Which if the past is any guide, won't stop someone from demanding we do extensive testing to disprove it.

 

[mike7877]

What would a counter do other than count pulses ?
When clocks are synchronized in a 400kHz rate all 3 clocks will have the same count and what would one do with a pulse counter ?



A counter is immune to jitter. It just counts periods.


Ideas are great. There is no practical benefit with your proposed method. In fact more likely the opposite. Switching between clocks is bound to have timing issues which you plan to avoid.

Put another way:
When 1000 pulses were counted by 2/3 or 3/3 of the slave clocks, and this was before the master clock hit cycle 2, the master clock would be slow, so the 1000th pulse would be used to re-sync the master clock and be used by the DAC as the 2nd cycle. And if the master clock was fast (1000 pulses not counted yet by 2/3 or 3/3 slave clocks), the second cycle would be counted by when the 1000th pulse was counted on 2/3 or 3/3 of the slave clocks

I'm not trying to restart the debate here, just clarifying because you asked

 

[mike7877]

This, I think, is the crux of the issue. What problem is being solved by the technical improvement? If none, then the improvement is just an intellectual exercise for the designers and a hook for the marketing people.

Some things need to become sufficiently advanced before they can become a part of (or inspire) a new creation. Even jitter... In the future, it's extremely likely we will require lower jitter clocks than are available today. If I had to guess, I'd say probably for a physical application of something related to advanced physics

Humans should always be striving for better!
IMO


Somewhat related: I wonder what the electronic equivalent of a weighted flywheel is...

 

[MAB]

Some things need to become sufficiently advanced before they can become a part of (or inspire) a new creation. Even jitter... In the future, it's extremely likely we will require lower jitter clocks than are available today. If I had to guess, I'd say probably for a physical application of something related to advanced physics

Humans should always be striving for better!
IMO

This is audio. While I couldn't follow how your thought construction would improve jitter of a given system (probably degrade I think), there are lots of ways to improve jitter. Your CPU has clocks operating several orders of magnitude higher frequency than audio, has jitter, and manages to not mis-compute because of the logic, not despite the jitter.

Somewhat related: I wonder what the equivalent of a weighted flywheel is in electronics...

A tank circuit. Literally called the flywheel in a buck converter.

 

[kchap]

There are real engineers out there in world who are not concerned about audiophiles claims of hearing the sub 100db harmonics caused by jitter. They are busy trying to keep large communications networks in sync while keeping jitter and wander under control. GPS has improved things a lot but does not solve all problems.

It's a complex discipline that I, along most of ASR's members, just vaguely understand. I suspect there would only be a handful of members with the engineering and mathematics skills to discuss the subject.

Let's discuss something at my skill level. I like cables with a woven outer sheath because they look nice.

 

[DonH56]

Jitter was a big problem in my (former) day job dealing with multi-GHz data links. We tested for something like 20 or 30 different jitter components (typres). At audio frequencies, not so much, not for a couple of decades now.

Last time I tried to explain a complex subject (FP ADCs) I got called ignorant and a liar. Not really interested in going down that path again trying to explain in a few words why trying to switch among high-speed clocks based on some sort of "jitter sensor" is impractical and unnecessary.

I like chocolate milk.

 

[Blumlein 88]

Some things need to become sufficiently advanced before they can become a part of (or inspire) a new creation. Even jitter... In the future, it's extremely likely we will require lower jitter clocks than are available today. If I had to guess, I'd say probably for a physical application of something related to advanced physics

Humans should always be striving for better!
IMO


Somewhat related: I wonder what the electronic equivalent of a weighted flywheel is...

The very latest most accurate clocks beyond the current standard are so accurate they can compare clock rates to detect a difference in the passage of time due to gravitational differences when one clock is 2 cm higher than another. They can be built in the size of a fridge and may in time become affordable for science to use it for various things. Will they improve audio one little bit? Not a chance. Will someone make a DAC with one, probably if they get cheap enough.

So it makes sense to strive for better if there is a use. Otherwise you might uncover one or not. Things interact in strange unforeseen ways. Yet they'll do you no good in audio.

New type of atomic clock keeps time even more precisely

An MIT-designed atomic clock uses entangled atoms to keep time even more precisely than its state-of-the-art counterparts. The design could help scientists detect dark matter and study gravity’s effect on time.

news.mit.edu

The World's Most Accurate Clock | Chemistry And Physics

The world’s most accurate clock has taken the 2022 Breakthrough Prize in Fundamental Physics. Jun Ye, a physicist with the joint venture of the Natio | Chemistry And Physics

www.labroots.com

Loses or gains one second in a time slightly longer than the age of the universe.

 

[Philbo King]

Jitter was a big problem in my (former) day job dealing with multi-GHz data links. We tested for something like 20 or 30 different jitter components (typres). At audio frequencies, not so much, not for a couple of decades now.

Last time I tried to explain a complex subject (FP ADCs) I got called ignorant and a liar. Not really interested in going down that path again trying to explain in a few words why trying to switch among high-speed clocks based on some sort of "jitter sensor" is impractical and unnecessary.

I like chocolate milk.

I spent 12 years in the Advanced Technology Center of an aerospace company designing very low jitter clock oscillators and making literally multiple thousands of phase noise measurements using an Agilent 5052. I too hesistate to make forum replies because of the attitude and bias of many of the people who reply here, unless it's a very simple topic that can be verified by a link to a wiki entry. It's just not worth it.

 

[mcdn]

Put another way:
When 1000 pulses were counted by 2/3 or 3/3 of the slave clocks, and this was before the master clock hit cycle 2, the master clock would be slow, so the 1000th pulse would be used to re-sync the master clock and be used by the DAC as the 2nd cycle. And if the master clock was fast (1000 pulses not counted yet by 2/3 or 3/3 slave clocks), the second cycle would be counted by when the 1000th pulse was counted on 2/3 or 3/3 of the slave clocks

I'm not trying to restart the debate here, just clarifying because you asked

You’re confusing clock sync with jitter. Your proposal has some utility for keeping 3 clocks in sync, but that’s not the same thing as jitter. Synchronisation means each clock counts the same number of pulses over a certain interval. Jitter is about the regularity of the exact arrival time of each individual pulse. Averaging pulses just makes the pulses blurrier. Modern DAC receivers use the medium term average of the pulse arrival frequency to reconstruct the clock at the receiving end, thus removing any jitter in the source.

 

[solderdude]

Put another way:
When 1000 pulses were counted by 2/3 or 3/3 of the slave clocks, and this was before the master clock hit cycle 2, the master clock would be slow, so the 1000th pulse would be used to re-sync the master clock and be used by the DAC as the 2nd cycle. And if the master clock was fast (1000 pulses not counted yet by 2/3 or 3/3 slave clocks), the second cycle would be counted by when the 1000th pulse was counted on 2/3 or 3/3 of the slave clocks

I'm not trying to restart the debate here, just clarifying because you asked

This does not help jitter at all it would just mean that from the moment the circuit came online the slower one would be ignored.
Jitter is not the same as frequency. It is the pulse width changing slightly or some relatively slow and low frequency 'drift'.
Most jitter in a DAC, however, does NOT come from the clock frequency but from data/clock transport and gates in digital circuits.
Improving jitter in the clock thus does not help with jitter reduction of the device.

Somewhat related: I wonder what the electronic equivalent of a weighted flywheel is...

Phase Locked Loop
It is a variable oscillator which frequencies will be governed (through an low pass filter which is the flywheel) by an incoming frequency it tries to match.
There is jitter there too of course as no oscillator nor digital circuit does not have it. It just needs to be low enough for the circuit (application).

Why would jitter in the future become more of a problem and why would solutions you try to invent help there if you do not have any deep understanding of the mechanisms behind it.

 

[Hayabusa]

This does not help jitter at all it would just mean that from the moment the circuit came online the slower one would be ignored.
Jitter is not the same as frequency. It is the pulse width changing slightly or some relatively slow and low frequency 'drift'.
Most jitter in a DAC, however, does NOT come from the clock frequency but from data/clock transport and gates in digital circuits.
Improving jitter in the clock thus does not help with jitter reduction of the device.

The OP talks about synchronized clocks not free running clocks
quote: "reference the clock that drives the clocks"

 

[voodooless]

In the future, it's extremely likely we will require lower jitter clocks than are available today. If I had to guess, I'd say probably for a physical application of something related to advanced physics

Note that you don’t necessarily need lower jitter to tell more accurate time. Jitter of an atomic clock is not up-to audio standards, but it’s time accuracy is measured infractions of ppm (parts per billion). That’s a few orders of magnitude better than your audio clocks.

 

[solderdude]

The OP talks about synchronized clocks not free running clocks
quote: "reference the clock that drives the clocks"

When you synchronize a clock the one that is synchronized is free running.
All clocks are free running.
So when you synchronize 3 clocks (and not 1:1000 pulses) you basically use the first clock and use the other 3 clocks as 'gates' with their own noise (jitter) on top of the jitter of the first clock.
As the output of a X'tal and the 'sync inputs' of the 3 following clocks have a finite frequency range and inputs of clock circuits have a decision point where low becomes high there will be jitter added there too.

 

[Hayabusa]

When you synchronize a clock the one that is synchronized is free running.
All clocks are free running.
So when you synchronize 3 clocks (and not 1:1000 pulses) you basically use the first clock and use the other 3 clocks as 'gates' with their own noise (jitter) on top of the jitter of the first clock.
As the output of a X'tal and the 'sync inputs' of the 3 following clocks have a finite frequency range and inputs of clock circuits have a decision point where low becomes high there will be jitter added there too.

I thought the experiment was as this:
1 clock to synchronize to (for instance the SPDIF clock)
N pll's that lock to that.
Then some circuit that combines these N clocks.