Imagine if the buffer monitor (because it outputs at the fixed DAC clock rate) told the motor controller to speed up a little because it was getting low on buffered data, or slow down, as necessary.
I'll have to perform the experiment again.
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Jitter stew
- Thread starter alfe
- Start date
Imagine if the buffer monitor (because it outputs at the fixed DAC clock rate) told the motor controller to speed up a little because it was getting low on buffered data, or slow down, as necessary.
I'll have to perform the experiment again.
You are correct. I don't know what led to me saying it was CAV instead of CLV. I corrected my post.
That is something that could easily be designed today. But CD design came from capabilities of low cost design back in late 1970s. So a much simpler scheme was deployed.
I went back and found the diagrams for the Philips CD-104 player. Here is the key part:
As you see, the clock is driven from front-end of the drive toward the DAC, not the other way around.
That is how it was done in olden days. Today I am pretty certain optical drives just spit out S/PDIF which doesn't have feedback loop to slow down or speed up.
I think that is completely the wrong way round, Amir. In all integrated audio CD players, the DAC is driven from the master clock, and the transport is servoed to the clock i.e. its speed is controlled purely by the fill level of a FIFO buffer that is being drawn upon by the clock. As long as the bits get off the disc at more-or-less the right time, the platter speed and its wow, flutter and jitter are completely irrelevant. This is a direct analogue (so to speak) for asynchronous systems now.
Edit: changed from DAC "being" the clock to DAC being driven by the master clock.
Last edited:
As for my hazy memory of stepped speeds, I'll assume that was what I remember seeing was during track skipping, and not intra-track, so a smoothish change in motor speed is correct (and I stand corrected) on that point, for CLV.
Here's a nice little paper by someone close to the subject.
http://www.analog.com/media/en/technical-documentation/application-notes/3778247647198AN324.pdf
I'll stick my microphone onto the drive chassis and record the sound of the spindle motor as it plays, and during track change, for grins.
Here's a nice little paper by someone close to the subject.
http://www.analog.com/media/en/technical-documentation/application-notes/3778247647198AN324.pdf
I'll stick my microphone onto the drive chassis and record the sound of the spindle motor as it plays, and during track change, for grins.
Last edited:
Are you talking about uber high-end players with custom drives? Or any CD player? If the latter, I like to see the block diagram showing the same.
Regardless, let's agree that any CD transport with S/PDIF output does not have any asynchronous capability as there is no return channel.
Yes, the irony being that as soon as the DAC was separated from the transport for audiophile reasons, the perfection of the system (that I think was there from the start) was lost, and suddenly the system had two clocks in it, and the DAC had to adjust itself to the transport's clock.
It has taken some finding, but I think here it is: a data sheet from 1987 for the SAA7310 that, it appears, was still being used 6 years later in Arcam CD players and others.
This, I think, is telling us that if the FIFO is 50% full, the motor speed is left unchanged. If the FIFO begins to empty, the motor is sped up, and vice versa. It was/is a perfect system.
This, I think, is telling us that if the FIFO is 50% full, the motor speed is left unchanged. If the FIFO begins to empty, the motor is sped up, and vice versa. It was/is a perfect system.
The servo controller may do that but not at behest of any independent DAC clock. Here is the block diagram of the Philips player again:
See how the DAC comes from upstream logic. In this regard, the DAC is certainly at the mercy of the PLL/motor drive speed controller.
See how the DAC comes from upstream logic. In this regard, the DAC is certainly at the mercy of the PLL/motor drive speed controller.
It's not the DAC clock specifically (I changed the wording of my earlier post ) but it is the system 'master clock'. It drives the rate at which data is fed out to the DAC from the FIFO. The motor is controlled to keep the FIFO at 50% full on average. In this sense, it is exactly like an asynchronous USB system where the data storage and delivery system is slaved to the DAC's sample rate, and timing is irrelevant as long as it gets the data there on time. Motor speed 'jitter' has no effect whatsoever on the output. The sample rate (and the jitter) is purely that of a crystal oscillator, with the motor slaved to that speed on average.
Last edited:
A synchronous system where everything is locked to a master clock is by definition not asynchronous. A USB async DAC has the freedom to select the ideal clock source for the DAC, not with any concerns as to what it needs to generate to run a motor servo system.
The delivery of the data from the disc is not synchronous with the clock, but is slaved to the consumption of the data effectively by the DAC. In this way, it is directly analogous with an asynchronous DAC, where the delivery of the data from the cloud/memory/server is not synchronous with the DAC's sample rate, but is slaved to the DAC's consumption of it.
The optical disc was the only way they had of storing large quantities of data. Now there are other methods, but the basic idea is *exactly* the same! (They weren't stupid).
And semantics aside, the fundamental point is: the motor's jitter/wow/flutter does not reach the output *at all*.
Why not? All that activity from the motor will couple into the follow on circuits. And given its high current draw, that is significant source of such noise/jitter. That activity can easily couple electrically or through air into the rest of the circuit including all the way into the DAC itself.
To build a correct, high-performance, asynchronous integrated DC player, you would make the whole front-end of the drive slave to DAC clock. Further, you run the optical drive in data mode so it starts and stops as needed to fetch the next chunk of data. This is again what Meridian does and it puts control where it needs to be (i.e. the DAC). That is the point of async design, not having asynchronicity for the sake of it.
This (the perfection of the CD system) is an example of a beautiful idea. In fact, it is an example of a perfect idea. Your comment above is just low level 'noise'. Of course the activity of a motor could break through to some extent if the electrical design was shoddy, but that applies to any and every electronic circuit: it has to reject power supply fluctuations, nearby taxi radios, and all the rest of it. But that is separate from the perfection of the idea.
Perhaps this is why nothing in audio is ever settled: people don't see the distinction between a perfect idea - which is a platform on which to build - and the almost-irrelevant other minutiae of engineering. The result is that people don't realise when they have perfection in their grasp, e.g. digital audio itself, and instead are persuaded that it is equally valid to scrape a pointy thing through a plastic groove to hear the recording.
Last edited:
Start and stop the motor or vary its speed, both in response to feedback - it is equivalent.
Don Hills
Addicted to Fun and Learning
The bottom line, as shown by all concerned including the diagrams supplied by Amir, is that the clock that ultimately drives the DAC in a "conventional" CD player is a fixed rate clock. It is not adjusted in response to variations in disc read speed, for example. Instead, the disc speed is adjusted to keep a buffer filled. No clock adjustment = no jitter (in a perfect world). As has also been pointed out, when buffer memory became cheaper some later players read the data in bursts instead of continuously. This was driven partly by the desire for longer battery life and increased skip resistance in portable players, which often read as much as 30 to 60 seconds of samples at a time.
I find it ironic that the rationale behind 2-box players was that possible noise generated in the drive mechanism was isolated from the DAC circuitry. In solving that problem, they created a new one with the S/PDIF jitter. Were there any models which fed clock back from the DAC box to the drive box?
I find it ironic that the rationale behind 2-box players was that possible noise generated in the drive mechanism was isolated from the DAC circuitry. In solving that problem, they created a new one with the S/PDIF jitter. Were there any models which fed clock back from the DAC box to the drive box?
Trouble is, the "almost-irrelevant other minutiae of engineering" is where digital playback breaks, or works, from a subjective viewpoint. 25 years ago, everyone who had aspirations for quality sound poured vast amounts of poo upon digital, it was close to a universal attitude amongst the cognescenti - and listening to the specimens around the traps one could understand why - it was a pretty miserable low class sound, that ticked many boxes technically, but failed to deliver 'musicality', however you wish to to understand that term. This was a curious situation for me, because I knew how good digital replay could be, but virtually no-one was experiencing it at the time.
Things have been changing rapidly recently, and many people have "seen the light" - I see the chance for major movement forward; the "battle" between analogue and digital is largely yesterday's news.
Quite a number over the years did that ...
Ok, I looked into this previously, but has anyone anywhere produced any measured evidence that these usb cleaners, e.g. regen, produce any improvement in a dac output by virtue of "improving" the usb eye pattern?
As far as I am concerned it is a misplaced correlation that makes little sense. If any particular dac shows an improvement it betrays the fact that it is a poor design.
As far as I am concerned it is a misplaced correlation that makes little sense. If any particular dac shows an improvement it betrays the fact that it is a poor design.
Similar threads
