Building a proper input & oversampler (i.e. front-end) for PCM1704

[silvercans]

So I've done some reading and have decided to go the oversampling route, please don't try to convince me otherwise

That said, I wanted to use the DIR9001 followed by the DF1704, but I don't want to use any of the clk signals they generate to avoid jitter. I want to take the data from the DIR and generate new clean SCKO,BCKO,LRCKO signals, feed that into the DF1704 and then generate new clean BCKO and WCKO singals that feed into the dac chips (PCM1704).

I only would support fs of 44.1 and 96k, I don't care about other input fs. How hard would it be to do this and what would be involved?

I can easily get a clean clock that generates 44.1khz for example (which would be my new LRCKO) then use a precise PLL to generate SCKO and BCKO but how would I synchronize that with the LRCKO generated by the DIR? (Similarly the same process for clks out of the DF1704, but again synch would be the issue)

Thanks for your feedback

P.S. I don't have FPGA experience so I don't want to go down that route, hence why I want to use DIR and DF

[SoNic_real_one]

You cannot "clean" the jitter as you said. You need as a minimum a sizable buffer memory and a DSP clocked independetly to achive what you say.
PLL will just "follow" the incomming jitter.

[abraxalito]

Your 'clean' clock will only be as clean as what the DIR9001 gives you from its on-chip PLL. Not very clean in my experience. To really clean up jitter you'd need to implement a secondary PLL. This could either be an analog or a digital one. Its fairly pointless to clean up the DF1704's jitter without addressing the jitter from the DIR9001.

[silvercans]

Correct, a pll will just follow the jitter. Hence I wanted to use and external clean clock for fs and a pll to generate system clock (512 * fs), bit clock, etc. That said, do you know what hardware specially that I can use that are low cost and would get the job done?

[abraxalito]

If you're going to use an external clock then your transport ( or whatever you're using as your source) will also need to be slaved to the same clock. Is this going to be the case?

[silvercans]

Originally Posted by abraxalito

If you're going to use an external clock then your transport ( or whatever you're using as your source) will also need to be slaved to the same clock. Is this going to be the case?

Not necessarily because my idea is to have the DIR deal with the source, extracting the data and from there use cleaner clocks then what the DIR puts out (same clk frequencies as whatever the DIR outputs, just cleaner). That said, I may need to store the data in memory then clock out, but there's got to be a way just to replace the clks the DIR is outputting with new ones at same freq and synched (the synched part is where I don't know what to do)

[abraxalito]

You'll need some way to regenerate the original clock though, even if you store the data in memory and then clock it out. Having memory means you don't need to get so close to the original clock frequency (you get some slack by virtue of the storage), but you'll still need some way to approximate to it. That's the function of a PLL - with a memory buffer you'll probably be implementing some kind of digital PLL.

<edit> What you want to do is something like what's described on the last page of this paper by Dan Lavry : http://www.lavryengineering.com/white_papers/jitter.pdf

[SoNic_real_one]

The only way to reconstruct the signal and get rid of the jitter is to have a buffer memory between the incoming signal and the DAC clock. That memory will require some DSP for the read/writes. Some proper upsampling+oversampling with dithering, linear interpolation (or other) is possible at this stage.

Denon does it with "AL24 Processing Plus", Harman Kardon does it with "Real-time Linear Smoothing" (RLS III, IV), CA in Azur line calls it ATF (licensed from Anagram) and Q5... usually done with something from Analog Devices Black Fin DSP family or TI TMS320 DSP family.

[silvercans]

Originally Posted by abraxalito

You'll need some way to regenerate the original clock though, even if you store the data in memory and then clock it out. Having memory means you don't need to get so close to the original clock frequency (you get some slack by virtue of the storage), but you'll still need some way to approximate to it. That's the function of a PLL - with a memory buffer you'll probably be implementing some kind of digital PLL.

<edit> What you want to do is something like what's described on the last page of this paper by Dan Lavry : http://www.lavryengineering.com/white_papers/jitter.pdf

If I use a pure memory solution, I would probably set flag bit(s) along with the data to indicate what the original fs was, but that would involve DRAM (or some other high speed memory) along with at least a micro-controller to control the memory timings, addressing, etc, thats getting too complicated. So, I'm after simply splicing/replacing the clock outputs that the DIR generates and outputs (three clks, LRCKO which is nothing more then fs extracted from the SPDIF signal, SCKO and BCKO, the last two can be generated via a pll off of the new stable fs that generates LRCKO)

by the way, I appreciate everyone's input and feed back!

[abraxalito]

Originally Posted by SoNic_real_one

The olny way to reconstruct the signal and get rid of the jitter is to have a buffer memory between the incoming signal and the DAC clock. That memory will require some DSP for the read/writes.

DSP isn't necessary - no processing (the 'P' in DSP) of the data is called for. A fairly simple microcontroller could handle it. Even a PIC or AVR could do it, given a big enough buffer memory size and appropriate I/O interfaces (I2S or similar).

Some proper upsampling+oversampling with dithering, linear interpolation (or other) is possible at this stage.

That kind of stuff would probably call for a DSP or DSC.