Asynchronous reclocking

[Ulas]

I don’t understand how asynchronous reclocking reduces jitter. Elso describes his asynchronous reclocker as “a low jitter clock with a 100MHz crystal and 74VHC74 flip-flops.” I haven’t seen the schematic but I assume the 100MHz clock drives the clock input of the flipflop, the D input is driven by the SCLK output of the CS8412, and the Q output drives the BCLK input of the DAC. There is nothing to be gained by reclocking the data or FSYNC because it is usually a BCLK edge that changes the analog output of the DAC.

The CS8412 outputs a new sample every 1/44100 seconds. That’s one sample every 64 SCLK periods or 22675.73696 ns. So, if the first sample comes at time 0ns, the second sample will come at time 22675.74ns, the third at time 45351.47ns, the fourth at time 68027.21ns, etc. Oh, there may be as much as 200ps RMS jitter and that’s VERY BAD.

Adding the 100MHz asynchronous reclocker simply advances each sample-time to the next multiple of 10ns, which means every sample will be output between 0 and 9.999999ns later than it should. That’s an average of 5ns of jitter, which is 25 times WORSE than the timing provided by the CS8412!!!

This spreadsheet, ARCjitter.zip , presents the above data in tabular form, which may be easier to understand, and allows you to try different reclocker frequencies to see the effect they have on jitter.

[Peter Daniel]

That's an interesting observation. Recently I've been using a DAC without reclocking and to me it sounds better than one with asychronous reclocking (suggested by Elso). I'm still not sure why?

[A 8]

For some reason I can't open the attachment, anyway not that I am into this type of reclocking but even if it creates more jitter as you describe it can decouple any signal/data/transport dependent jitter which I guess could be a benefit.

Could it be that it then has the same effect as dither!?

[tschrama]

Furthermore....

1/44100 Hz / 200ps is 113E3. So if such an timing error would be in the middle of a giant transient high pitched sound, the error would be only -101dB, comfortably below 16bit resolution..

Can somebody elaborate?

Regards,
Thijs

[Jax]

After nearly 20 years as a digital electronics designer I have learned one thing:

Asynchronous reclocking never work.

A reclocker will, depending on the relationship between BCLK and the reclock source, reshape the noise caused by jitter. I myself would prefer the whiteish noise from random jitter rather than the predicted result from a reclocker. But that's me.

It's always better to clock the DAC first, then feed the clock back to the source. Any jitter from the source to the DAC will be limited to the clock itself near the DAC as long as no setup or hold times are violated. The most important is the jitter between the BCLK edges that clock the word latch signal.

[Pedja]

Originally posted by Ulas
(…) Oh, there may be as much as 200ps RMS jitter and that’s VERY BAD.

Adding the 100MHz asynchronous reclocker simply advances each sample-time to the next multiple of 10ns, which means every sample will be output between 0 and 9.999999ns later than it should. That’s an average of 5ns of jitter, which is 25 times WORSE than the timing provided by the CS8412!!!

This spreadsheet, ARCjitter.zip , presents the above data in tabular form, which may be easier to understand, and allows you to try different reclocker frequencies to see the effect they have on jitter.

So, did you try one (still asynchronous) reclocker running at the frequency which is the multiple of 44.1kHz (say 22.5792MHz or 45.1584MHz)? It should not have the problem you have described (your spreadsheet does not have enough resolution to show this). Have compared it with “completely” asynchronous one (like Kusunoki’s or Elso’s)? I would appreciate if you are ready to share that experience.

There is nothing to be gained by reclocking the data or FSYNC because it is usually a BCLK edge that changes the analog output of the DAC.

Sorry, but soundwise this simply does not have a lot with reality. However, it might have something more with some theory. One might say, hence worse for reality…

Originally posted by Peter Daniel
That's an interesting observation. Recently I've been using a DAC without reclocking and to me it sounds better than one with asychronous reclocking (suggested by Elso). I'm still not sure why?

What was the problem you have encountered?

Originally posted by Jax
After nearly 20 years as a digital electronics designer I have learned one thing:

Asynchronous reclocking never work.

I was not aware of the fact that the asynchronous reclocking was used for 20 years.

Pedja

[Peter Daniel]

Originally posted by Pedja

What was the problem you have encountered?

There was no problem at all. It's just that the DAC without reclocking sounded better (more natural and real with better highs and bass). But again, those DACs were not exactly the same, the better sounding had less PS filtering and instead of discreet regualtor had an AN8005 reg.

I am building presently a DAC with Kusunoki reclocking scheme, where I can remove 74VHC74 chip and connect I2S lines directly. This will give me the most clear picture what is actualy better. I will post the results soon.

[Pedja]

Thanks for the answer. I thought it was the same DAC, with and without reclocker.

[Jax]

Originally posted by Pedja
I was not aware of the fact that the asynchronous reclocking was used for 20 years.

Pedja

I was talking about digital design in general, not just digital audio

Besides, the closer to a multiple of Fs your reclock source are, the worse. Crystals have a tolerance, usually 50ppm.

[Ulas]

On the same subject, here is a trivial spreadsheet, ARCslip.zip, which computes the number of samples dropped or repeated when using a DDDAC style reclocker.

To evaluate the audibility of jitter and dither, I wrote this little program, jitterdither.zip. The included source code should answer any questions about what the programs does. Recompile it if you are wary of viruses in downloaded exe files.