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.
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.
-Won
Actually, some transports already have such buffers, I think.
-Won
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?
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.
Now, when I built my new DAC with Burr-Brown 1704 parallel chips the Technics doesn't even come close.
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 ?
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 ?
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.
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.
rbroer,
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:
http://www.anidian.com/audio/construct/adac_1.shtml
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.
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:
http://www.anidian.com/audio/construct/adac_1.shtml
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.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.