> Reclocking with 100 MHz Clock
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.
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)