Asynchronous reclocking

[tschrama]

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

[ojg]

Originally posted by Pedja
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!

[Ulas]

Originally posted by tschrama
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.

[ThorstenL]

Konnichiwa,

Originally posted by Ulas
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

[Pedja]

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

[Peter Daniel]

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

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

[Ulas]

Originally posted by Kuei Yang Wang

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.

[Pedja]

Originally posted by Peter Daniel
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

[Peter Daniel]

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.

[Pedja]

Hi Peter,

I did not try reclocker in the TDA1543 DAC. Will report somewhere about it when/if I try it (certainly not in the next few months, busy with some other stuff).

Pedja