Building a proper input & oversampler (i.e. front-end) for PCM1704 - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 8th February 2011, 06:04 PM   #1
diyAudio Member
 
Join Date: Oct 2005
Default Building a proper input & oversampler (i.e. front-end) for PCM1704

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

Last edited by silvercans; 8th February 2011 at 06:08 PM.
  Reply With Quote
Old 9th February 2011, 12:25 AM   #2
diyAudio Member
 
Join Date: Jan 2008
Location: Virginia
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.
  Reply With Quote
Old 9th February 2011, 12:29 AM   #3
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to 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.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 9th February 2011, 12:30 AM   #4
diyAudio Member
 
Join Date: Oct 2005
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?
  Reply With Quote
Old 9th February 2011, 12:33 AM   #5
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to 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?
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote
Old 9th February 2011, 12:39 AM   #6
diyAudio Member
 
Join Date: Oct 2005
Quote:
Originally Posted by abraxalito View Post
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)
  Reply With Quote
Old 9th February 2011, 12:43 AM   #7
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to 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
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler

Last edited by abraxalito; 9th February 2011 at 12:46 AM.
  Reply With Quote
Old 9th February 2011, 01:28 AM   #8
diyAudio Member
 
Join Date: Jan 2008
Location: Virginia
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.

Last edited by SoNic_real_one; 9th February 2011 at 01:46 AM.
  Reply With Quote
Old 9th February 2011, 01:37 AM   #9
diyAudio Member
 
Join Date: Oct 2005
Quote:
Originally Posted by abraxalito View Post
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!
  Reply With Quote
Old 9th February 2011, 01:41 AM   #10
diyAudio Member
 
abraxalito's Avatar
 
Join Date: Sep 2007
Location: Hangzhou - Marco Polo's 'most beautiful city'. 700yrs is a long time though...
Blog Entries: 98
Send a message via MSN to abraxalito Send a message via Yahoo to abraxalito Send a message via Skype™ to abraxalito
Quote:
Originally Posted by SoNic_real_one View Post
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).

Quote:
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.
__________________
It doesn't have to take the form of a conspiracy, rather a consensus... James H Kunstler
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Building Eggleston rosa clones , any input ? elecres Multi-Way 5 2nd January 2011 05:23 PM
New to tube building / design - Input requested! Zap Tubes / Valves 19 19th November 2007 08:31 AM
building an A/B speaker switch - would appreciate input JMB Multi-Way 6 16th June 2006 11:26 AM
DSP card & proper xover for heathkit 859A speaker cabinet x. onasis Multi-Way 6 22nd April 2003 07:39 PM


New To Site? Need Help?

All times are GMT. The time now is 04:13 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2