I have known about async reclocking for a long time but never was too motivated to really bother really getting into it (never considered actually building a DAC). but recently I began considering it, read some postings here and there and something stroke me: it looks like my understanding of this thing was not accurate. I always thought that the only logical way to implement this is to reclock with a multiple of Fs right before the DAC. but some seem not to do it like that and I'm wondering why would anyone do it any other way. please enlighten me.
I am puzzled by this too. It seems to guarantee that some samples will either be dropped or repeated, possibly several times a second, as the two clocks will not be at exactly the same speed. I would expect that to sound worse than a little jitter.
Jitter gives a tiny error on every sample. Async reclocking gives a much smaller error on most samples, but a whacking great big error on a fairly regular basis.
Jitter gives a tiny error on every sample. Async reclocking gives a much smaller error on most samples, but a whacking great big error on a fairly regular basis.
Could be financial reason: a 100 MHz low-jitter clock might be cheaper than a 11.2896 or 16.9344 MHz low-jitter master clock. Also the absolute jitter at 100 MHz is less than the absolute jitter at 11... or 16... MHz. It is absolute jitter that matters at reclocking. Synchronous reclocking to the low-jitter master clock is the perfect solution.
You are not missing anything; your better judgement has not failed you and you are correct to be suspicious of this kludge called Async reclock.
Async reclock increases the jitter to one period of the new clock. At 100 MHz as suggested above, that's 10 ns, or 10000 ps. Async reclock increases jitter. Full stop.
Async reclock increases the jitter to one period of the new clock. At 100 MHz as suggested above, that's 10 ns, or 10000 ps. Async reclock increases jitter. Full stop.
that's an interesting point and a reasonable explanation.
so you're basically saying that it's hard to find a "N x Fs" clock that has low enough a jitter so that we're not defeating the porpose? what about the Tent clock?
I was considering a minimalistic (not that I'm an adept of the concept but rather I'm going for the effort/results ratio) approach, asynchronously reclocked with Tent XO, NOS, filterless PCM56 or whatever R2R, Pass I/V stage, battery powered, S/PDIF-fed DAC.
There was a long thread several years ago by one of the founders of Silicon Labs describing how this works. I've summarized the theory here: H I F I D U I N O: How Asynchronous Rate Conversion Works and here: http://hifiduino.blogspot.com/2009/06/asynchronous-re-clocker-vs-asynchronous.html
There is a big difference between "reclock" and "resample"
There is a big difference between "reclock" and "resample"
Asynchronous audio DAC re-clocking is a whole different matter than asynchronous sample rate conversion. Async. sample rate conversion involves the calculation of new samples to support, with low distortion, a different sample rate going out than coming in. Async. re-clocking doesn't change the incoming samples, it changes the timing of when they are converted by the DAC chip.
I can't see how my question implied that I'm confusing the two.
I'm talking about reclocking done in order to reduce jitter, and nothing more. the situation that I'm describing in the original posting has nothing to do with resampling, this issue is treaded separately and not part of the question.
Asynchronous reclocking is usually done by cascading 2 D flip-flops. Both flip-flops receive a low jitter clock signal from a non-synchronized clock, 50 MHz for example.
The first D flip-flop output can only change on the positive going edge of the low jitter clock. This theoretically blocks source jitter.
But one cannot make sure that the input signal on the D input is always fully stable at the moment the sample is taken (both clocks don't run synchronous / drift).
So there are situations where the output of the D flip-flop still contains jitter because the input signal wasn't stable (1 or 0) when the sample was taken. In order to fix this, a second D flip-flop is added that re-samples the output of the first flip-flop. Now the input signal for the second D flip-flop is always stable during sampling.
In short, for asynchronous reclocking we need at least 2 D flip-flops.
With synchronous reclocking we can make sure that the input signal at the D input is stable the moment it is sampled, so here we only require a single D flip-flop.
There is a catch, since the low jitter clock has limited frequency, the resampled signals fall into time slots of 1/f. For a 50 MHz low jitter clock this means time slots are 1 / 50,000,000 = 20 ns.
During asynchronous resampling no samples are lost and bit-perfect playback is guaranteed. But since the reclocked signals have to fall into 20ns time slots (example), unwanted harmonics are added to the resampled signals. These are caused by the fact that two non-synchronized clocks of different frequency inter-modulate.
This is not the case with synchronous reclocking where both input clock and low jitter sampling clock have to run in sync and thus can't inter-modulate.
In order to achieve lowest jitter levels, it is best to synchronously reclock the I2S signals just before they enter the DAC chip. This basically requires slaving the source.
The D flip-flops aren't perfect, and thus add jitter to the reclocked signal. This jitter can be minimized by choosing D flip-flops with lowest possible propagation delay, operating at lowest possible voltages (in order to minimize ground-bound that also increases jitter). This means that the popular 74HC(T) series D flip-flops are less suitable as they have too high propagation delay (check clock to Q propagation delays in the datasheet).
Fastest available D flip-flops are (P)ECL versions, however there are also few suitable ultra high speed CMOS D flip-flops. Also make sure to use single D flip-flops, each located in a separate IC package, each with a separate power supply decoupling in order to minimize crosstalk between D flip-flops.
Last edited:
John,
I've been noting your association of gate propagation delay with jitter. A uniform time delay, no matter how long, doesn't create jitter. For example, how long is the delay from when a CD was initially recorded to when is is played? Therefore, I assume you are concerned about minute variations is propagation delay - the window for which are presumably reduced as overall prop. delay is reduced. What is the mechanism of concern connecting gate prop. delay and jitter as you see it?
Last edited:
John, nice explanation of metastability. Some more reading on the topic:
Metastability in electronics - Wikipedia, the free encyclopedia
What Is Metastability?
Metastability in electronics - Wikipedia, the free encyclopedia
What Is Metastability?
thanks for the detailed answer.
you even anticipated some questions. ground bounce is one issue I'm planning to address.
You start with a false supposition. Can you PROVE that flipping in the edge blocks the sorce jitter? Of course NOT.
If the source has jitter, that jitter will be found EXACTLY on "moving back and forth" the rising/falling edges of the incoming signal. So it will be transmitted 100% thru a D-FlipFlop. No blocking, just transparent passing trough.
The rest of the post is based on the above false statement, so... it cannot be true.
Last edited:
Anything on the D pin inside the reclock period by several nanoseconds for AC logic is going to wind up having the stability/phase noise of the flip flop clock plus its own noise. It works. Better if you can manage to keep both oscillators from running within several nanoseconds of each other's transitions.
"Inside reclock period"??? What if the period is different than the source period (and will be)? In time, the difference can mean that you will periodically skip a sample (or double one, depending of the sign of the difference).
Is that what you seek by "jitter ellimination"? Compounding it on longer periods of time?
Keeping the periods equal require a PLL.
Alternativelly you can use a buffer memory and zero it in the silence between the songs.
Is that what you seek by "jitter ellimination"? Compounding it on longer periods of time?
Keeping the periods equal require a PLL.
Alternativelly you can use a buffer memory and zero it in the silence between the songs.
Last edited:
All seems a bit backward looking to me. The obvious way to do it is to burst-download the data to some memory in the DAC, clock that out with a local clock while you're downloading the next block into a second memory bank. USB Audio Class 2 makes this possible since last year as I understand it, and there's a new interface Lightpeak/Thunderbolt coming on new Macs and USB 3 too.
The problem is Class 2 drivers, there's a Linux one, but only proprietary ones for Windoze. Still, I'd be hanging fire on building a DAC on any of the old schemes. Not that I think the jitter really makes much difference, but if you can design it out fairly easily and cheaply it avoids a load of bickering.
w
Course it's no good if you're looking for something to bolt on to some SPDIF source.
The problem is Class 2 drivers, there's a Linux one, but only proprietary ones for Windoze. Still, I'd be hanging fire on building a DAC on any of the old schemes. Not that I think the jitter really makes much difference, but if you can design it out fairly easily and cheaply it avoids a load of bickering.
w
Course it's no good if you're looking for something to bolt on to some SPDIF source.
Last edited:
That's correct... Some buffer/cache memory is the right way to eliminate jitter.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.