DAC clock frequency dividers

[3nity]

Hi,

I went through this old thread.
I was wondering if today there's a better solution on deriving MCLK, BCLK and LRCLK from a low jitter oscillator, using frequency dividing IC's.
And keeping low RMS jitter figures.
Especially for the use with ASRC's output port in slave mode.

Opinions?

[SoNic_real_one]

You NEED to keep the clocks in sync with the input signal. That is why all the receivers have a PLL loop. So your ideea of a "low jitter" cannot be acomplished in a simple way.
Solutions are:
- you have a low jitter in your signal source. If that is optical an ANY point is hard to achieve. That includes any transformation before it hits a storage medium (like a HDD).
- you have a big cache memory and a DSP so you can us two clocks. One for writting the data (with incomming jittery data rate recovered by the PLL loop) and one ultrastable/low jitter to read the stored data.
Why you need the cache? So you don't miss/repet any samples due to instantaneous differences between the two frequencies.
- you can use a ASRC chip fed from a precise clock. That ASRC will use some internal ROM tables to "approximate" the missing/added samples generated by the same instantaneous differences between the two frequencies.

[3nity]

Thanks for the reply.
I was thinking of using what you expressed in your 3rd option:
precise clock feeding the ASRC in slave mode and the DAC.
The receiver to the ASRC input port.

My original question was about the clock dividing network, though.

Any comments?

[SoNic_real_one]

Well, you have no reason to "create" BCLK and LRCLK clocks. The reproduction side of the digital chan uses those clocks in order to syncronize the data read from the digital storage medium, you cannot just "create" them from outside, they have to be in sync with the medium. Even if you use an ASRC, they still have to be generated internally in that ASRC.
Personally I don't think the dividers are the problem, most of the jitter comes from mechanical tracking of optical medium used to store (at some point) the digital signal.

[3nity]

Originally Posted by SoNic_real_one

You NEED to keep the clocks in sync with the input signal. ...
- you can use a ASRC chip fed from a precise clock. That ASRC will use some internal ROM tables to "approximate" the missing/added samples generated by the same instantaneous differences between the two frequencies.

how would you use this option?
S/PDIF receiver pll feeding ASRC input port, then ASRC generating the System clock and bclk + lrclk for the DAC?
Not clear to me when the precise clock that feeds the ASRC is coming into picture.

A link to some schematic would be really helpful.

Thank you.

[rfbrw]

Originally Posted by 3nity

A link to some schematic would be really helpful.

My latest project - DAC + headphone amp

[3nity]

Originally Posted by rfbrw

My latest project - DAC + headphone amp

Thank you!
So with this configuration, the ASRC works in a 'de-jitter' scheme.
With it's Input port as a slave and being clocked by the 256*Fs precise clock,
and Output port in Master Mode, deriving the BCK and LRCK for the DAC chip.

Originally Posted by SoNic_real_one

- you have a big cache memory and a DSP so you can us two clocks. One for writting the data (with incomming jittery data rate recovered by the PLL loop) and one ultrastable/low jitter to read the stored data.
Why you need the cache? So you don't miss/repet any samples due to instantaneous differences between the two frequencies.

That would be like the Esoteric D-70, right?
I have read the schematic, but no knowledge on how to accomplish this.
It involves MPU programming.

Has anyone tried this solution?
Any readings to suggest?

T.Y.

[rfbrw]

Genesis Technologies Digital Lens
TOTALDAC DAC

[SoNic_real_one]

Unfortunatelly the only "cheap" way to do reclocking at DYI level is with an ASRC chip. AD, TI, AKM and CS have each a version, with the AD one suposelly having the best results. But all of them will approximate some samples periodically. How much is that "audible" is left to debate.

The buffer method involes some DSP programming and it was tried in a few devices. Esoteric D-70 had 128MB of memory to acomplish that cache. Genesis used 512kB in their product Digital Lens.
Newer, chinese Musiland has a FPGA based product that supposely is asyncrone with a FIFO cache, but something gets lost in translation. That FPGA has 216kB of internal dual-port RAM.

[rfbrw]

I always understood reclocking meant the data was left untouched. That you could do that with a device that resamples all incoming sample rates within a given range to one specific output sample rate is news to me but then again so is the need to use a DSP chip just to track FIFO pointers.