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.
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.
Last edited:
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?
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?
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.
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.
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.
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.
That would be like the Esoteric D-70, right?SoNic_real_one said:
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.
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.
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.
Last edited:
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.
You cannot leave data "untouched" when you do reclocking. Untouched data has incorporated the time-domain jitter. If you have another frequency to "reclock", even if thoretically is the same value, in reality, it will be different. And the incoming one will be variable in time (jitter-modulated). Inevitabilly some data samples from the incoming stream will be either repeated or skipped periodically if you don't apply some kind of buffering (large enough to compensate for short and long term delta f). The pointers can be reseted to point in the middle of cache memory in the silence break between the songs (nobody cares if you loose/repeat samples there).
What ASRC/SRC cips are doing is avoiding repeating or skipping by "creating" an intermediare value for the sample that is to be repeated and same for the one after the skipped one. They have preprogramed coeficients to do that.
What ASRC/SRC cips are doing is avoiding repeating or skipping by "creating" an intermediare value for the sample that is to be repeated and same for the one after the skipped one. They have preprogramed coeficients to do that.
Last edited:
Reclocking and resampling are not the same thing. In this context, reclocking tracks a given sample rate. When data is reclocked with a PLL, a FIFO or a simple '74 flip-flop the data is untouched. If it wasn't you couldn't reclock HDCD data and as the application notes for both the PMD100 and the PCM1732 include PLL based reclocking schemes, I'll take that as a good indicator that the data is indeed untouched.
An ASRC is something completely different and there is plenty of information around to explain how it works but here is as good as place to start as any.
An ASRC is something completely different and there is plenty of information around to explain how it works but here is as good as place to start as any.
In the end is the same thing... When you "reclock" actually you resample with the same clock value. The "simple" flip-flop scheme doesn't do nothing good for the jitter, just "repairs" the transitions, making the jitter embedded permanent in the signal.
FIFO is usefull only if it is big enough to cache a few seconds worth of data.
PS: HDCD decoders won't work with a different samplerate because of the baseband signaling system of the encoding. It doesn't mean nothing more or less. It was supposed to be extended into 48/96kHz for DVD use with the PCM200 and further, but the history was different. DVD-A/SACD came in and out, MS bought the HDCD and shelf it...
FIFO is usefull only if it is big enough to cache a few seconds worth of data.
PS: HDCD decoders won't work with a different samplerate because of the baseband signaling system of the encoding. It doesn't mean nothing more or less. It was supposed to be extended into 48/96kHz for DVD use with the PCM200 and further, but the history was different. DVD-A/SACD came in and out, MS bought the HDCD and shelf it...
Last edited:
Following the incoming data with a PLL is not "reclocking". Is just recuperating the embedded clock. "Re-" implies a change of that clock...
OP asked how to best divide MCLK to produce low jitter bit and word clocks for using with an ASRC in slave mode. Most of the following replies made no sense at all.
I'd say avoid a ripple counter and try something like the 74 161 or 163.
I'd say avoid a ripple counter and try something like the 74 161 or 163.
Hi guys,
Thanks for the replies so far.
At last, I think the most viable solution is to set the ASRC output port in master mode, reclocking on pin 3 (MCLKI on AD1896 or RCKI on SRC4192) from a stable clock, and let the chip derive the BCK and LRCK.
Those synchronous counters (161 through 163) have a propagation delay of 9nS at best.
Will they perform better in the division wrt ASRC chips?
Any experience on this?
For the MCLK generation, I was keeping an eye to the Vanguard golden can TCXO's. They claim .3ppm stability. Has anyone tested them in a project?
I was thinking of using it as xo in the Kwak clock. Any comment?
T.Y.
Thanks for the replies so far.
At last, I think the most viable solution is to set the ASRC output port in master mode, reclocking on pin 3 (MCLKI on AD1896 or RCKI on SRC4192) from a stable clock, and let the chip derive the BCK and LRCK.
Those synchronous counters (161 through 163) have a propagation delay of 9nS at best.
Will they perform better in the division wrt ASRC chips?
Any experience on this?
For the MCLK generation, I was keeping an eye to the Vanguard golden can TCXO's. They claim .3ppm stability. Has anyone tested them in a project?
I was thinking of using it as xo in the Kwak clock. Any comment?
T.Y.
- Status
- Not open for further replies.