Asynchronous reclocking

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
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.
 
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!?
 
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.
 
Ulas said:
(…) 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…

Peter Daniel said:
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?

Jax said:
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
 
Re: Re: Asynchronous reclocking

Pedja said:

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.
 
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.
 
Re: Re: Asynchronous reclocking

Pedja said:
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).

Remember that the two clock frequencies will never be exactly the same, one will be 44101 while the other will be 44099. So on average the jitter will still be Ts/2, for a 45.1584 clock this is 11ns.

However the jitter-spectrum will change and have a strong low-frequency component, while for the 100MHz clock the jitter is almost entirely random. The spreadsheet shows this very well, nice work Ulas!
 
tschrama said:
Sorry, but it won't compile nor execute on my system (MS VC++ 6.0) ...... can you make a 'robuste' executable that for sure will run.. I am sincerely curious what you made...

Regards,
Thijs

Sorry, but I have no idea what your problem may be. I just downloaded the zip file from the link I posted on this site. The exe worked properly. I created a new (empty) workgroup with VC++ 6.0, loaded the source files to the appropriate folders, compiled and executed with no problems. As far as I am concerned, there is nothing wrong with the files.
 
Konnichiwa,

Ulas said:
Sorry, but I have no idea what your problem may be.

Shame. I don't keep Mickeysoft kompilers around and your EXE does not run either at home or at work (both PC's are W2K). Maybe it needs a dll or controll you have and the rest of us has not?

Also, on topic, having the worst clock difference I have ever seen documented (5000ppm) results in 800 dropped samples per minute or 13 Samples per second. On many CD's your CD-Players error correction will have "interpolated" (read ballsed up) more samples than that.

To go further, yes, asyncronous re-clocking with a non-integer multiple clock of sample frequency introduces significant levels of jitter, however their spectrum and distribution will be much different from that of the source jitter, one might argue that the source jitter is "randomised" by such asyncronous re-clocking.

I would see little difficulty from asyncronous reclocking at integer multiples of the sample rate, the dropped samples should be relatively unproblematic, sonically. Using other frequency clocks will clearly have an audible effect, exactly what will depend upon the resulting jitter spectrum, something which squares with the experiences of Kosonoki San who is the first source of async reclocking using non integer multiples of the sample frequency.

Your spreadsheet certainly has given me something to think. External clocking of the CS8412/14 and re-clocking before the DAC are quite easy and we don't drop enough samples to make it worrysome.

Also, the spreadsheet has other interesting uses. It tells us that for the biggest difference between source and nominal clock we need to buffer around 62k Samples and have another 62k samples to spare to make sure that a 80minute CD does not over or underflow a memory buffer.

In other words, 3 seconds worth of samples or 8MB worth of memory needs to be fitted to buffer a full CD, on the assumption that we use the receipt of "digital silence" as a "reset" signal that re-aligns the buffer to 1/2 full by either stuffing digital silences or omiting them in the buffer.

Now 128MB PC Memory DIMM Modules cost next to nothing, how about a little project to make a CS8412/14 receiver plus buffer using a simple cheap 128MB DIM. We don't need to address the whole Memory Space, if we use 44100 X 64 Bit X 6 Seconds as initial delay we would fill up 16MB of the buffer and then have to keep another 16MB as overflow space, the rest can be used by a PIC as it's memory? Or are there affordable and fast PIC's that have > 32MB on board Memory to handle the buffer job? Then follow up with a reclocker for the data lines (to eiminate jitter from the PIC) and generate your word and system clcok directly of a X-Tal, switchable for 32/44.1/48KHz sample rates (derivation for 64/88.2/96 et al should then be easy).

Sayonara
 
I was curious and took OJG’s jittertest.wav file (thanks OJG) to check the jitter of my Marantz CD63SE, Kusunoki style DAC and TDA1514A non-o/s DAC with Elso Kwak’s ASR-3. The results confirm that the reclocked DAC has far highest jitter. Sixteen bit resolution of the used soundboard was the limiting factor here but many things were still showed nicely. The CD63’s sidebands were hardly visible in the noise floor which was about 110dB below the signal’s peak (IIRC Hi-Fi Choice has measured about 550ps jitter). My Kusunoki style DAC showed a few visible peaks (Stereophile has measured 1.47ns for 47Lab’s Progression DAC). The TDA1541A DAC with ASR-3 was notably worst. I could compute this (or upload the graphs somewhere if someone is interested) but it is roughly close to the expected more than 10ns (ASR-3 runs at about 60MHz, not 100MHz).

So, with this testing I could finish the story about the asynchronous reclocking (as well as the Philips’s DACs) and start to look around for some better solutions for my digital source. The only problem with ASR is the fact it sounds excellent (yes Peter, I saw what you wrote in the other thread :eek:). And I am not the number hunter. Is it the answer randomization/de-correlation? Maybe. Maybe not. I had a plan to clock the flip-flops with the multiple Fs frequency but still did not do it. Maybe I will soon.

Pedja
 
Pedja said:
The only problem with ASR is the fact it sounds excellent (yes Peter, I saw what you wrote in the other thread :eek:).

I'm also not the numbers hunter and jitter means nothing to me. But for my curiosity, could you elaborate how subjectively the reclocking improves the sound (in your experience)?

As a side not, after my first implementation of Elso's asynchronous reclocking, I also thought that I'm getting improvement, I even said that in some older posts and mentioned what changes (for better) I was getting.

But since then, my musical taste changed somewhat (as my amplification and speakers), and I'm looking for different things when listening to music now. In both comparisons (Kusunoki style reclocking and Elso's asynchronous on all three lines, compared to not reclocked digital signal), I don't see anything to be gained, quite opposite, the sound becomes more digital and less analog (when reclocking, to be specific).
 
Kuei Yang Wang said:
Shame. I don't keep Mickeysoft kompilers around and your EXE does not run either at home or at work (both PC's are W2K). Maybe it needs a dll or controll you have and the rest of us has not?

That’s a too bad. I originally developed the program two years ago, with the same compiler, on Win2K. I recently updated it to change the jitter specs from ppm to ps, which seem to be the preferred notation, and did the build, with the same compiler, on WinXP Pro. I just transferred the exe to a stock Dell laptop running Win98SE and ran it with no problems. I guess some things were not meant to be.
 
Peter Daniel said:
I'm also not the numbers hunter and jitter means nothing to me. But for my curiosity, could you elaborate how subjectively the reclocking improves the sound (in your experience)?

As a side not, after my first implementation of Elso's asynchronous reclocking, I also thought that I'm getting improvement, I even said that in some older posts and mentioned what changes (for better) I was getting.

But since then, my musical taste changed somewhat (as my amplification and speakers), and I'm looking for different things when listening to music now. In both comparisons (Kusunoki style reclocking and Elso's asynchronous on all three lines, compared to not reclocked digital signal), I don't see anything to be gained, quite opposite, the sound becomes more digital and less analog (when reclocking, to be specific).
Actually next sentence does not apply to you. I know you are not the number hunter, and the fact you are designing your devices on the ear is the thing I appreciate even if we are not in the agreement with our findings.

As far as I can remember at this moment (it is almost morning here), when I reclocked the SCK line the main thing was that the sound become more liquid, putting the flip-flops on the other two lines (at once) improved the dynamics. I should cut the traces on the PCB or unsolder the flip-flops to take step back so I did not do that (I consider step back always a highly revealing thing), but having always the small (not reclocked) Kusunoki DAC as some orienting point (it made me sober a few times), I can say for sure the sound of my TDA1541A is now notably better than that. It was not thus when I compared them while TDA1541A was not reclocked – common base I/V stage contributed to this too, but ASR’s participation was not negligible.

Pedja
 
Hi Pedja,

If I understand this correctly, reclocking improved in your case TDA1541 chip, but you did not mention anything about reclocking TDA1543. As Elso commented, with different chips he got different results and some reacted better for reclocking that others (AD1865 vs TDA1543 which was not so much improved by reclocking, IIRC).

I will try reclocking with TDA1541 as well. I just don't like it with the 1543 chip.
 
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.