By follow URLs and in the attached files you will find various schematic of reclocking units in front of the DAC IC.
I don't understand the individual pros and cons.
At first look the russian approach seems to be the best solution.
But I am not really sure.
Which of this examples is to prefer?
Digital decoding of biphase-mark encoded serial digital signals
Reproduction equipment for digital audio
I don't understand the individual pros and cons.
At first look the russian approach seems to be the best solution.
But I am not really sure.
Which of this examples is to prefer?
Digital decoding of biphase-mark encoded serial digital signals
Reproduction equipment for digital audio
Attachments
-
Reclocking from Russian - Schema MCK-Reclock-DAC D20400.jpg -
Reclocking from Russian - Schema SPDIF Receiver.jpg -
Reclocking from Russian - Schema VCO & Line Buffer.jpg -
Reclocking from Russian - Theory of Operation-I.pdf
-
Reclocking from Russian - Theory of Operation-II.pdf
-
Reclocking from Russian - Theory of Operation-III.pdf
-
Reclocking PCM63.pdf
-
Reclocking SM5842AP & PCM63 schema.pdf
-
Reclocker for TDA1541 schema.pdf
-
Reclocker for TDA1543 schema NOS.pdf
Last edited:
First one is based on D-flip-folps... Garbage, it will miss or repeat samples periodically, based on instaneous difference of frequencies (source and local). End result - higher distortions. Some people like them...
Second one is not a reclocking is just a classic SPDIF receiver connected to the PCM100 digital filter.
Last one is a schematic for slaving a transport to the DAC. Like that is gonna solve anything... th ejitter from the transport will still be preset at the output (without a bigger RAM buffer than the usual 2K) and DAC will just produce higher distortions than without "slaving".
All in all none of the above will offer "jitter reduction". If it was THAT simple (D-latches) all the industry would have already implemented that.
Contrary to the general belief, electronic engineers are not morons or memebrs of a secret conspiracy to produce bad sounding devices.
Second one is not a reclocking is just a classic SPDIF receiver connected to the PCM100 digital filter.
Last one is a schematic for slaving a transport to the DAC. Like that is gonna solve anything... th ejitter from the transport will still be preset at the output (without a bigger RAM buffer than the usual 2K) and DAC will just produce higher distortions than without "slaving".
All in all none of the above will offer "jitter reduction". If it was THAT simple (D-latches) all the industry would have already implemented that.
Contrary to the general belief, electronic engineers are not morons or memebrs of a secret conspiracy to produce bad sounding devices.
Last edited:
Some (most) companies spare a 10c D-flip-flop or capacitor if they can. Some (most) consumers do not notice the difference, because they are not in the position to compare.
It's not that trivial a problem to solve, unless you can control the flow of data from the source.
Here's a very interesting article on how to re-clock data from a USB stream using a PLL:
The D/A diaries: A personal memoir of engineering heartache and triumph
Or you can presumably go for the asynchronous sample rate conversion route, and re-sample the incoming data at the very slightly different clock rate of your DAC, but this would change the 'bits' - though in almost a theoretically perfect way. Something like this:
http://www.analog.com/en/audiovideo-products/sample-rate-converters/ad1896/products/product.html
Here's a very interesting article on how to re-clock data from a USB stream using a PLL:
The D/A diaries: A personal memoir of engineering heartache and triumph
Or you can presumably go for the asynchronous sample rate conversion route, and re-sample the incoming data at the very slightly different clock rate of your DAC, but this would change the 'bits' - though in almost a theoretically perfect way. Something like this:
http://www.analog.com/en/audiovideo-products/sample-rate-converters/ad1896/products/product.html
Last edited:
That is your (minority) opinion. The facts suggest otherwise. We have had that argument in another thread, so I'm not trying to carry it on here just alert people to the conventional view.SoNic_real_one said:
Most simple attempts at reclocking swap one form of jitter for another, typically much worse. Doubling or dropping of samples will happen. As you say, this leads to garbage yet it curiously seems popular.
Agreed, although those who have some experience of EEs while they are still students may feel that their education has significant shortcomings. They are taught to repeat the mantra "digital good, analogue bad" by their teachers, and as a result may have little interest in learning how to do good analogue circuitry and may be overly confident in the abilities of digital stuff.
You are kidding! People do this?!
As the links I posted above show, the problem is to all intents and purposes solved. It's not something I've ever tried to do, myself, although I sometimes have to 're-clock' other types of digital stream in my work (PLLs are things of beauty aren't they?).
Do CD transports ever provide an input to allow the DAC to regulate the flow of data - which would obviously be the simplest and best solution? Presumably this is what happens in the typical non-audiophile CD player that houses the transport and DAC together.
Last edited:
I believe it is known as asynchronous reclocking. The idea appears to be that as the derived clock from SPDIF is too horrible, simply substitute a local crystal clock at nominally the same frequency. No attempt is made to lock the clocks together. Drift will therefore mean either duplicated or dropped samples at the difference frequency rate - typically several times a second?
Having the DAC regulate data might be better, as up to the DAC output the timing does not matter too much - before that point the data is just that - data. However, the conventional solution tries to deal correctly with the problems: CDP-DAC link introduces high frequency jitter, which the receiver PLL eliminates. In addition, the clock recovery circuit uses the parts of the signal which are least likely to be corrupted. My guess is that most of the jitter seen by the DAC originates in the CD player clock, which is why improving the clock may be worth doing.
"PLLs are things of beauty aren't they?"
Not according to Dan Lavry, he should still have his white papers on his site explaining why PLLs are the spawn of the devil. Always use the DACs clock as the master.
Lavry Engineering - Unsurpassed Excellence
Not according to Dan Lavry, he should still have his white papers on his site explaining why PLLs are the spawn of the devil. Always use the DACs clock as the master.
Lavry Engineering - Unsurpassed Excellence
If you mean this one, he says no such thing. He explains the limitations of PLL, fairly well but in terms which might alarm the uninitiated. He then introduces his solution. To sell someone a solution, you first have to convince them that they have a problem. Some do this by telling lies. He doesn't do that, but carefully chooses how he expresses the truth. He says, correctly, that a PLL can't eliminate jitter below the filter cutoff frequency. He doesn't emphasise, as far as I can see, that a typical system will not have much jitter in this frequency region - provided it has a good clock. This is simply the art of the salesman.
I agree with you about the sales skills. And with the fact that most EE have no experience when they finish schools. But they are not the ones that controll the design of new cips/equipments. In charge are old guys with plenty of experience (including analog) and having loads of measuring tools and focus groups. To say that those are all BAD and only some DYI guy that works in a garage is GOOD is fullish.
If a D-flop would do the magic to "reclock", you would see that incorporated in the receiver cips already! It would be free and provide a sales point! Something like the small FIFO buffer that Wolfson has in their WM8804 SPDIF receiver.
And yes, the high-frequency jitter is eliminated more or less efficient this days by the modern receivers. DAC's are also more immune to it.
The jitter that is still present is the low frequency one. Generated by motor/CD inertia, motor PLL loop that is tunned on the same frequency (to be able to track the relative error).
"Slaving" the transport or providing a "better" clock does ZERO to fix that source of jitter. Better mechanisms, better motors, higher rotational inertia can do that. Or bigger FIFO buffers.
If a D-flop would do the magic to "reclock", you would see that incorporated in the receiver cips already! It would be free and provide a sales point! Something like the small FIFO buffer that Wolfson has in their WM8804 SPDIF receiver.
And yes, the high-frequency jitter is eliminated more or less efficient this days by the modern receivers. DAC's are also more immune to it.
The jitter that is still present is the low frequency one. Generated by motor/CD inertia, motor PLL loop that is tunned on the same frequency (to be able to track the relative error).
"Slaving" the transport or providing a "better" clock does ZERO to fix that source of jitter. Better mechanisms, better motors, higher rotational inertia can do that. Or bigger FIFO buffers.
Last edited:
Admittedly I'm coming to this without much knowledge of the interior details of CD players, but I don't know what this means! I would have thought that if I can tell the transport that my FIFO is full ("slaving" the transport to the DAC) then its motor, inertia etc. is of no significance whatsoever. When my FIFO empties to a lower limit, the transport can be told to start sending data again. Isn't this how it works?
From your answer it's almost as though even the "slaved" CD transport is working like a digital version of a vinyl turntable. Maybe someone should think this outboard DAC thing through again!
I presume that a PC takes the sensible approach to reading an audio CD (like a data CD), and that's how I thought ordinary CD players worked as well...
Last edited:
Yeah, that was a bit (well actually a lot) of hyperbole and I admit that I know next to nothing about the internal machinations of digital.
On the other hand I also frequent a pro audio forum and a few people who know what they are doing measured the jitter of Dacs internal clocks compared to having it clocked by an external, more accurate clock. In all cases when the dac was slaved the jitter was worse than when using the dac as a master.
Although that was years ago around the time I bought my interface.
Now forget everything I wrote. I'll stay out of this from now, it'll be better for all concerned. ;-)
On the other hand I also frequent a pro audio forum and a few people who know what they are doing measured the jitter of Dacs internal clocks compared to having it clocked by an external, more accurate clock. In all cases when the dac was slaved the jitter was worse than when using the dac as a master.
Although that was years ago around the time I bought my interface.
Now forget everything I wrote. I'll stay out of this from now, it'll be better for all concerned. ;-)
I believe the link I posted earlier concerning the humble PCM2702 USB DAC is about something very similar to the Lavry device:
Don't worry about it. SoNic_real_one is mistaken, but refuses to be convinced otherwise. The RAM buffer, even in old CD players, is sufficient to cope with transport jitter. The jitter that remains comes from the crystal clock itself.CopperTop said:
Putting the master clock at the DAC makes sense, as it would reduce the scope for problems. Of course, a one-box system does that! Two-box systems have gone for the convenience of an embedded clock, which means one connection instead of two. Maybe this is because SPDIF is derived from a professional standard, where long leads are more common and two long leads (clock one way, data the other) would lead to clock delay problems?
Like I said, 2kBytes of RAM doesn't make more than 5milisec of buffer. You say that is plenty, I say that is not enough for low-freq jitter...
And agree to disagree on this.
Of course the high frequency jitter is derived directly from the crystall reference. And a better crystal might improve THAT jitter. But the HF jitter is eliminated easy by the modern receivers and even DACs, so why spend hundreds of dollars/euros for a super clock when you can take care of that jitter easier on DAC end?
And agree to disagree on this.
Of course the high frequency jitter is derived directly from the crystall reference. And a better crystal might improve THAT jitter. But the HF jitter is eliminated easy by the modern receivers and even DACs, so why spend hundreds of dollars/euros for a super clock when you can take care of that jitter easier on DAC end?
Last edited:
No, clock jitter will be mainly low frequency. A crystal will not pass frequencies much removed from its own resonance so sidebands further out (=HF jitter) will be strongly attenuated. Of course, it is possible to introduce HF jitter via a bad clock design so some may be present. As you say, the receiver will eliminate HF jitter.
A better crystal will help, as crystal quality is important. Surface contamination is, I understand, a problem with many modern crystals as they are churned out by the million in scruffy factories. The result is frequency instability (freq domain) or jitter (time domain). Crystals are much cheaper these days, but a decent crystal is still expensive.
A better crystal will help, as crystal quality is important. Surface contamination is, I understand, a problem with many modern crystals as they are churned out by the million in scruffy factories. The result is frequency instability (freq domain) or jitter (time domain). Crystals are much cheaper these days, but a decent crystal is still expensive.
I really don't understand this. Surely we take a crystal clock and use this as our reference to drive the DAC output sample rate. The CD transport is nothing more than a slower version of a computer hard drive. It can random access given N milliseconds, and it can stream serial data at a maximum rate which is higher than stereo 16 bit 44.1 kHz. The rate at which it streams data may be variable and not necessarily related to the DAC clock at all. Some circuitry somewhere buffers the data being requested from the transport, and feeds this into the DAC at the crystal-derived sample rate. The transport merely has to keep up by sending chunks of data on request (at any old speed) to the buffer.
In a system with an out-board DAC, the buffer/clock doesn't feed the DAC directly, but interposes a SPDIF or similar interface. Unfortunately, the DAC circuit must then attempt to synchronise to a signal that has come over a longish piece of wire or optical cable and which therefore has introduced jitter.
Or that's how I had thought of it anyway. The most controversial part of this is that it suggests that the 'quality' of the transport is irrelevant, and that a £5 PC CD ROM will be just as good as anything else. Do audiophiles worry about the quality of the transport? If so, why?
Last edited:
CD players usually run at x1 speed, so the data comes off the disc at approximately the right speed. It is placed in a FIFO buffer, and read out using a crystal clock. The motor speed is locked to the crystal, but of course will vary a little. The motor servo will try to keep the buffer about half-full. The quality of the transport has an indirect effect on sound: poor focussing or track following means more work for the error correction to do with the potential for interpolation, poor PSU design or poor grounding can mean noise gets where it shouldn't. If working correctly, the transport has no direct effect on the sound as it simply has to deliver correct data at roughly the right speed.
It may be that some newer or cheaper units work more like a computer, with a fast drive and a massive buffer, but fast transports tend to be noisy.
It may be that some newer or cheaper units work more like a computer, with a fast drive and a massive buffer, but fast transports tend to be noisy.
- Status
- Not open for further replies.