RAM buffers for DAC? - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source
Home Forums Rules Articles diyAudio Store Gallery Wiki Blogs Register Donations FAQ Calendar Search Today's Posts Mark Forums Read

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
Thread Tools Search this Thread
Old 20th June 2002, 09:33 PM   #1
dorkus is offline dorkus  United States
diyAudio Member
dorkus's Avatar
Join Date: Jun 2001
Location: Mountain View, CA
Send a message via AIM to dorkus
Default RAM buffers for DAC?

i know this is an old question (i saw a manufacturer mention this in Stereohile as early as '88) but i'm wondering why more companies don't use a RAM-based buffer to reclock a digital signal before the DAC, thus making jitter from the transport irrelevant (at least in theory). i know the Chord DAC and maybe a couple others do it, but why is it not done more often? besides the slight time delay i don't see any drawbacks of this approach. does it not work as well as i think it should? i did a couple searches on the topic but didn't come up with much.
  Reply With Quote
Old 20th June 2002, 10:11 PM   #2
Won is offline Won
diyAudio Member
Join Date: Nov 2001
Location: Cambridge, Mass
Alot of DACs upsample/oversample, in which case the data is implicitly reclocked anyway (it goes through a stage of digital processing). Some people like to use the digital signal straight out of the transport into a DAC. These folks might be interested, but since they insist on using a jittery transport signal as inputs and steep low-pass filters at outputs, I doubt such a rational idea would appeal to them.

Actually, some transports already have such buffers, I think.

  Reply With Quote
Old 20th June 2002, 10:16 PM   #3
tiroth is offline tiroth  United States
diyAudio Member
Join Date: Dec 2001
Location: Pittsburgh, PA, USA
The DIR1701/1703 has a built-in FIFO. I like it.
  Reply With Quote
Old 20th June 2002, 10:17 PM   #4
dorkus is offline dorkus  United States
diyAudio Member
dorkus's Avatar
Join Date: Jun 2001
Location: Mountain View, CA
Send a message via AIM to dorkus
wouldn't you want the buffer as close to the DAC as possible? so not as part of the transport, but as part of the DAC. i bring this up because i was arguing with a friend over digital cables. i told him different digital cables do sound different, and he thought it was dumb to even bother with cables when you could just buffer the signal just before the DAC and not worry about the transport, cables, etc. altogether. it's a good point, but are we missing something here?
  Reply With Quote
Old 20th June 2002, 10:31 PM   #5
diyAudio Member
Peter Daniel's Avatar
Join Date: Jul 2002
Location: Toronto, Canada
Send a message via AIM to Peter Daniel
The DAC I was using untill recently was Technics X-1000, which in early 90's cost CAD$8,000. I bought it only because I got good deal on it with a matching transport. At that time it was good. It has RAM buffer and a "jitter free" switch. I must say that there was not really "big" difference when I disabled the buffer. And I also add that even with buffer engaged the type of cables used had the bigger difference than the RAM buffer itself.
Now, when I built my new DAC with Burr-Brown 1704 parallel chips the Technics doesn't even come close.
  Reply With Quote
Old 21st June 2002, 08:02 AM   #6
rbroer is offline rbroer  Netherlands
diyAudio Member
rbroer's Avatar
Join Date: Mar 2002
Location: Netherlands
Every transport has a FIFO buffer quite upstream of the chain.
You need it as far downstream as possible, preferably right before the DAC or even inside the DAC for best results.
For example, take the low budget Philips CD713 player.
A friend of mine installed a LCaudio-XO low jitter clock at the crystals original location (SAA737X decoder). The clock will go thorugh many gates inside the decoder, before being output to the TDA1545A dac; the signal derived from the clock signal will degrade from downstream of the connection point for the clock !
Now there were the typical improvements, but not really jaw-dropping. Now the bitclock (BCK) in this player just happens to be the same (44.1kHz*2ch* 4*oversampling*24bit frames) as the master clock, that is 8.4MHz. It's the same phase as well, so I connected my own DIY low jitter clock to the BCK input of the TDA1545A dac and to the decoder as well. Now this is as far downstream as possible, and sonics confirmed this; much better than the decoder only connection.
But.....even with clock connected directly to dac chip, seperate regulators for dac and output stage etc. this player is still very responsive to vibration control like vibrapods, mass loading and to mains filtering as well. The vibration thingie bothers me bigtime, didn't expect it with clock directly at dac...there are more things going on than one expects.

Tiroth, what a coincidence, I've been working on a pcb for the DIR1701 just this week. Sounds like the crystal connection to that chip should be a low jitter clock for best results if it is being used for reclocking the signals using buffers as you state.
Any additional hints/tips for this chippie ? Could you send me your circuit to verify my own design ?
  Reply With Quote
Old 21st June 2002, 08:22 AM   #7
diyAudio Member
ftorres's Avatar
Join Date: Apr 2001
Location: Limoges, France
I think the main point is not to store the serial data before they enter the DAC, but to output them with the right pace. RAM implies using additional circuitry to shift data in and out (provided the RAM chips are fast enough, which I'm not sure), and if you dig a little deeper, you'll end up with a FIFO (See Dave posts on subject).

FIFO or shift registers are to be used if you don't use an ASRC, and simple D flipflops are the best if you do.
"Learning French is trivial: the word for horse is cheval, and everything else follows in the same way."
  Reply With Quote
Old 21st June 2002, 03:14 PM   #8
tiroth is offline tiroth  United States
diyAudio Member
Join Date: Dec 2001
Location: Pittsburgh, PA, USA

I used a crystal and the 1701's internal oscillator (and PLL). Basically built it from the datasheet. While there is an argument for a quality external clock oscillator (lower jitter) there is also a problem of greater radiated EMI...which I considered worse, since in my application I already have two inharmonically related clock oscillators--didn't want to add a third. Also, I'm not even using the recovered MCK.

You can see what I am doing here:

I'll be updating these schematics Monday...there are mistakes, and they are out of date...but the DIR1701 schematic (in the reciever/distribution block) should be solid, as it is almost a copy of the circuit I built. I also have a PCB outline for a little DIP carrier board for the DIR1701...email me if interested.

The DIR1701 includes a PLL and clock multiplier to 100MHz, so it isn't clear exactly how jitter on the clock input affects the recovered MCK jitter. If you are using crystal mode (rather than PLL mode), that is a whole different can of worms, and I didn't investigate this.
  Reply With Quote


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
Chip buffers Atilla Chip Amps 27 9th January 2010 12:49 PM
Discrete buffers Ted205 Chip Amps 27 12th August 2008 09:13 AM
WTB: BUF-634 buffers in TO-220 package KT Swap Meet 1 24th July 2007 05:15 AM
FS : OPAMPS & Buffers dtm1962 Swap Meet 2 6th October 2006 06:43 PM
FS : OPAMPS & Buffers dtm1962 Swap Meet 0 4th October 2006 03:47 AM

New To Site? Need Help?

All times are GMT. The time now is 09:31 AM.

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

Content Relevant URLs by vBSEO 3.3.2