Reclocking with 100 MHz Clock
It has been discussed that one can use “asynchronous” reclocking with a high frequency clock, that is a clock frequency not a multiple of the source sample rate frequency. This method has been used in the past and good results have been reported. See for example reclocking the TDA1545 (Monica DAC) with an 80 MHz clock [link]
Many have planned (including myself) to use the on-board clock of the Buffalo DAC (and other Sabre32-based DACs) in order to achieve “ultra low jitter” results.
But, there are some problems with the ES9018 on-board sample rate converter when dealing with this kind of clocking.
Russ just reported the following:
A quick update – I will state up front – I was completely wrong.
I found the re-clocking via flip flop to the 100Mhz clock was actually destructive to a jittery signal. Not in the way you might think. It actually can cause a very slight error in the data. It definitely will not help. Someone called this a decimation error, but I am not sure that is the correct term.
After a while I noticed that the sound was actually worse… less precise, kinda murky. It sounded like jitter… ouch.
This is because the original bit clock reference which the ES9018 uses to tune the DPLL is completely lost. It becomes “aliased” or masked if you will with the master clock.. In other words It sees the damaged data as perfectly good defeating the super cool algorithm ESS designed to fix jitter… yikes not what we wanted at all now is it.
This mod makes it super easy for the DAC to lock, but now every 20 or so samples (I am not sure exactly how many – it depends on the rate) the data contains errors.. bummer. We shifted clock errors into the data domain… Only now – to our dismay – the DPLL is missing the source clock context it needs to *fix* the data! Bummer. We effectively defeat the DAC at one of the things it does best, Rejecting jitter.
If you refer to the ESS DPLL/ASRC patents it starts to make perfect sense.
Further – It was explained to me that the idea itself completely redundant. The reason is that the DAC *already* time aligns all inputs with the master clock during the process of re-sampling. and even better when it re-samples it does so in a loss-less way. You cannot make the flip flip circuit loss-less – thus the data error.
So chalk it it up to a fun, but tragically failed experiment. A valuable lesson learned.
It was an interesting idea, but alas, not a good one. My advice is to feed the signal to the DAC – and let it do what it does best. Don’t try to fix what ain’t broke.
This video gives a good glimpse into why such a mod is redundant:
It also very interesting in regard to digital volume control.
Yes! Analog is technically better , but only if your implementation can manage a -133db noise floor.
Good luck with that. It highlights just how good the volume control (and analog noise floor) of the ES9018 actually is.
Other DAC chips would be far better candidates for various re-clocking schemes.
Cheers!
Russ
The mental picture for this kind of reclocking was that the clock would be modulating the I2S signals with the 100 MHz frequency. The new signals would be like “pulse width modulated”. The question was how would the chip respond to that.
Therefore, the only viable solution at the moment is to use the source clock to synchronous reclock the I2S signals and to use the Sabre32 DAC in asynchronous or synchronous operation (which for a “low speed clock” results in the maximum sample rate that can be reclocked and the drawbacks of feeding the SabreDAC chip a “low frequency” clock)
H i F i D U I N O 
In a case like TDA1545 it should indeed work fine, but that’s a completely different animal.
Also to be clear – the problem is that anytime you try to directly reclock a jittery signal, you just end up capturing the error in a different way.
But one benefit of reclocking *some* sources is the effect of buffering/cleaning up the signal.
In this case even though all three signals where reclocked – it just moves the error into a new time domain. Only now the ASRC has no refernce that there is an error. 🙂
The problem grows worse as you increase the sample rate.
Does this mean that reclocking, like in the case of Ian’s FIFO, is less preferable to direct connection to the ESS DAC?
Ian’s solution is different in that it buffers the data and generates a brand new lower jitter I2S signal with a clock that is a multiple of the sample rate. So in Ian’s case, reclocking is preferable.
My personal opinion is that the end result (measured analog result and listening pleasure 🙂 ) even FIFO re-clocking will be no better in the case of the ES9018 when used asynchronously. It all ends up re-sampled to a different time domain anyway.
If you use the exact same clock domain for the DAC master clock and the FIFO the DPLL will free-wheel which is nice, but the analog result is the same as running asynch.
One way to think of the DPLL and the associated data path in the ES9018 is as a small depth FIFO in it’s own right. 🙂
For other DACs with no re-sampling the improvement with Ian’s FIFO would be very substantial indeed. I think that’s the ideal usage. I would love to put one in front of an Opus.
If you look at the actual analog output of a bone stock ES9018 with a 80-100Mhz clock – you will see there is so little jitter – even with a poor source – that it is hard to measure. With other DACs it is very obvious on an FFT. With the ES9018 The jitter simply does not make it through – as long as you have a good master clock.
Watch the video I posted earlier. Then read the patents if you have time. It’s really cool stuff. I just re-read them – I had forgotten how impressive those patents really are. 🙂
I think Ian’s project is very cool BTW. This comment is not meant to detract from it in any way. I just think it is much more useful for DACs like the DSD1794 or the WM8741 – or even the old TDAs.
Like I said – often less is more. In the case of the ES9018 I think the fifo is a solution looking for a problem. 🙂
I am sure reasonable people could disagree. No worries.
Cheers!
Russ
I printed the ASRC patent already (US7436333) 🙂
Hi, Russ,
It’s a good chance to catch you here.
> My personal opinion is that the end result
> even FIFO re-clocking will be no better
> in the case of the ES9018 when used asynchronously.
> It all ends up re-sampled to a different time domain anyway.
I have such a speculation that the shortest timing interval ES9018 architecture can generate internally in its DAC domain is the same as the MCLK interval. How do you feel about this?
It is always a pleasure to converse with you.
I would say based on the evidence before me that is correct. 🙂
Actually I can go further than that. ESS has told me (Actually I think Dustin said so directly on the forums) that there is no clock multiplication involved. So the smallest interval would have to the master clock interval.
Also when know for certain DACs work at Mck/64. Dustin said this as well. That means the bit clock of those DACs is of course the master clock – or actually at least no faster.
Cheers!
Russ
Hi, Russ!
I appreciated your immediate and kind replies very much!
Bunpei
So there’s no gain in trying to reclock the Amanero signal as it will be corrected when it reaches the Sabre DAC chip anyway
Is the isolation of the Amanero signal worth the effort?
I’m not sure I like the avatar you have selected for me, if I stop asking stupid questions will you change it 🙂
Isolation is to cut potential noise sneaking through I2S, reclocking helps the locking of the DPLL. So there is something to gain. Regarding the Avatar, I didn’t pay too much attention when I selected the “theme”, but the Avatars are assigned by WordPress. I just pick the theme :-). I thought they were kind of cute 🙂
For anyone who missed it this:
“After a while I noticed that the sound was actually worse… less precise, kinda murky. It sounded like jitter… ouch.”
That was an attempt at audiophile speak humor. Anyone who knows me knows I absolutely hate to talk “subjective speak”. In the future I will attempt to be mark my sarcasm better – as apparently someone thought I was serious… 🙂 I was not.
This post was not meant to be authoritative in the least! It is just an informal blog comment meant to keep the conversation going.
Humor having failed… the only practical point I was making was that *in my opinion* the re-clocking was an an exercize in redundancy at best, and possibly destructive. I tried to explain my limited, incomplete, and likely flawed understanding why – but I honestly am not 100% certain of anything yet. I want to be convinced! 🙂 Empirical evidence goes a long way. I didn’t present any – and I did not intend to. 🙂 My mind is open to learning more on the subject. DSP is not my forte’ – experts please weigh in if you like.
I would be glad if someone with good analytical gear can confirm my *theories*. I will be the first to tell you – I haven’t – I can’t. Simple as that.
So if somebody has the gear – here are some ideas for an experiment:
1) Use a source with controllable observable jitter for each signal (BCK,WCK,Data) – what I mean is to apply the error independently in a controllable amount would be cool.
2) You need an FFT capable of measuring the minute side bands associated with phase noise in the analog domain. It is the final effect we are after.
It may take a simulation to do this.
It is absolute fact that I cannot currently scientifically quantify to what degree aliasing a jittery signal to the master clock will degrade the signal – heck I don’t even know if it’s enough to matter.
You should try it for yourself if inclined. It’s great fun! And after all that’s the whole point.
I don’t expect nor want anyone to stop tinkering simply because I was not happy with my own experiment. Go pursue your own! Have great time. If you are capable of and have the gear for measuring and sharing the result – superb! I would love to see it. I don’t – so I won’t. I don’t expect you to take anyone’s musings as gospel – after all have not really even thought it all through for myself. 😀
If my tone was too absolute – well I will try to make it clear. I am not absolutely convinced of anything except that the music sounds good – and this is a great hobby.
I am after all – just another hobbyist. I am having fun and learning all the time, I hope you are too. 🙂
Cheers!
Russ
Hi Russ,
Here is some educated speculation:
I read the first part of the patent (and like any patent, it takes some effort in understanding what is going on). The ASRC basically replicates the input data points to the new time reference (the 100 MHz clock). Only when there is a transition, it wants to determine the error (how far away is the actual transition) to the new time reference and calculate an intermediate value equal to the error. It does this by using the DPLL to determine the actual frequency and inserts the correction by delaying the output signal. (still have not read the DPLL part in detail).
Now, based on this algorithm, it goes to great length in detecting the errors when it sees a transition (an edge in the incoming clock). If we now reclock the incoming clock with the 100 MHz clock, then all edges of the incoming clock coincide with the clock edges in the new time reference, so the error is always zero (which in practice, it cannot be). So I think the error calculating circuitry keeps attempting to find error until the signal can no longer be delayed any further and gives up until the next delay period.
Another way of thinking through this is that in the mapping of the incoming clock into the new time reference, it wants to be precise as to where the transitions happen. If we move the transition points with the reclocking, then we have defeated the use of ASRC and we have moved the edges ourselves to an inaccurate location in time…
I would say that is very close to the way I understand it as well.
You are right about reading patents those three patents in particular.
Ultimately we are blind to actual implementation.
You see what I mean about the pipeline being a kind of accumulator/FIFO in it’s own right?
Yeah, there is a “mini FIFO” used to insert the correction values when moving the data to the higher frequency time reference. But I think what “kills” reclocking is that we move the transitions from where they should had been. Now I am not sure if there is a difference between synchronous and asynchronous reclocking. Got to read more of the patent 🙂
I sense a mental convergence. 🙂
I was sure you must have been assigning them as some seemed very appropriate, even mine.
As I only have ears, and even those are a bit dodgy, my plan is to start with the Amanero stand alone then add the reclocker to see (hear) what happens, and then leave it up to my ears to make the decision. As you say we do it for fun not for grief.
Well said.
There’s also metastability. Say you reclock with an asynchronous 100 MHz clock. Quite often, the flop’s setup/hold times will be violated, and it will output something that doesn’t quite look like the original data.
That’s why properly crossing clock domains needs several flops in “series”, and a look at the error probabilities. When asynchronously reclocking BCK with a single flop, it is entirely possible to get stuff like double clock pulses, or out-of-spec BCK timings sent to the ESS dac.
So, perhaps it screws up the DPLL, but also, you’ll play the wrong bits, which is kinda problematic.
Also, input clock jitter dithers the input sample timestamps, and it is possible that it allows the DPLL to actually work better.
Thanks for your comment. Indeed reclocking with an asynchronous clock may not be such a good idea…
Care to expand on your last sentence: “Input clock jitter dithers the input sample timestamps, and it is possible that it allows the DPLL to actually work better”
Thanks…
Well, the dac measures the arrival times of BCK pulses, and this measurement is quantized as a number of MCK pulses. This is just like bit quantization in an ADC, and for the same reasons, adding a bit of noise on the incoming signal will reduce the quantization noise, but of course increase the overall amount of noise. This is a beneficial tactic if you have, say, a N bit ADC, digitize a signal with a few LSBs of noise on it, and filter the digital signal, you remove most of the noise, and you can get resolution much above N bits.
That said, I don’t think this is a valid explanation, just a wild hypothesis.
On the subject at hand, to explain the performance variation, I much prefer those 2 hypothesis :
– “audiophile experimenter” fails at tapping 100 MHz clock cleanly, implements flops on perfboard, creates large antennas and huge amount of digital noise
– and/or metastability, here’s a few example of the output of a flop which got its setup/hold timings violated :
http://www.asic-world.com/tidbits/metastablity.html
http://electronics.stackexchange.com/questions/26981/if-a-f-f-has-a-setup-violation-and-goes-metastable-is-it-guaranteed-to-settle-t
If this crap is presented to the DAC as BCK, it may well double-clock some bits, corrupting the digital data. Also, presenting a voltage close to Vcc/2 to a CMOS input like that will cause excessive current draw in the chip.
To cross clock domains you need several flops in series. The idea is that the first flop may do funny things, but as long as its output converges to the right value before the second flop samples it, all is good. The flop specs normally give the probability of it not converging in the required time, which is used to calculate the global error probability, which is never strictly zero, but can be in the style of “less that one failure in the age of the universe”, so practically zero. With just one flop though you’ll get many errors all the time.
sac gucci femme
iherb coupon
suchy stempel
tavistock bathrooms
fitta porr
It’s really a nice and helpful piece of info. I am happy that you shared this useful info with us. Please stay us up to date like this. Thank you for sharing.