OK, lets recalculate.
The RAW date at the laser pickup is 75 frames per second, each 2352 Bytes. That is 176400 Bytes/s=172.2 kBytes/sec.
To eliminate the jitter you need to write the data with the incomming rate (jittery) and read it at the constant rate (crystal driven). The the memory size needs to hold double the time frame desired to be corrected, because you start with the pointer in the middle of the buffer and that moves up and down based on instantaneous delta.
Also, the whole amount of RAM cannot be used just for FIFO, because it needs the "space" to de-shuffle also (some ammount of whole frames needs to be stored at any time).
That takes away some frames, but let's assume it doesn't count.
All in all, 2kBytes of memory can accomodate as FIFO less than 1/172.2 = 0.005 seconds of raw CD data. Even if it is used ALL for FIFO and nothing for de-shuffle! That is 5msec!
Motor tracking (inertia/friction-related) errors mentioned above have longer periods than that.
To me it doesn't look that much. I think it needs to be at least 20 times that value (0.1 sec) in order to take care of jitter down to 10 Hz domain... to take care of most of the mechanical influences.
The RAW date at the laser pickup is 75 frames per second, each 2352 Bytes. That is 176400 Bytes/s=172.2 kBytes/sec.
To eliminate the jitter you need to write the data with the incomming rate (jittery) and read it at the constant rate (crystal driven). The the memory size needs to hold double the time frame desired to be corrected, because you start with the pointer in the middle of the buffer and that moves up and down based on instantaneous delta.
Also, the whole amount of RAM cannot be used just for FIFO, because it needs the "space" to de-shuffle also (some ammount of whole frames needs to be stored at any time).
That takes away some frames, but let's assume it doesn't count.
All in all, 2kBytes of memory can accomodate as FIFO less than 1/172.2 = 0.005 seconds of raw CD data. Even if it is used ALL for FIFO and nothing for de-shuffle! That is 5msec!
Motor tracking (inertia/friction-related) errors mentioned above have longer periods than that.
To me it doesn't look that much. I think it needs to be at least 20 times that value (0.1 sec) in order to take care of jitter down to 10 Hz domain... to take care of most of the mechanical influences.
Last edited:
How many buffers are there? The raw data needs to be buffered, which is what we are talking about. What about deinterleaving, error checking and recovery, header removal etc. - they need buffering too? The DAC only sees the timing from the final buffer - before then all we have is pure data so it simply needs to be passed on uncorrupted.
Also, given that a bit of memory array is fairly cheap, my guess is that the relevant chips have enough memory to do their task. If not, it would be simple for a rival to come out with a chip which had more memory for a slightly higher cost and eat the others' lunch. I know it is fashionable to assume that mainstream audio designers and chip manufacturers are simply incompetent, and of course they don't get everything right, but I think we can assume that on such a simple issue with such a simple solution they have done their sums correctly.
The low frequency performance of the motor is set by the PLL locked to the crystal clock. The high frequency performance is set by mechanical inertia from angular momentum. All that is left is mid-frequency for the FIFO buffer to handle.
Also, given that a bit of memory array is fairly cheap, my guess is that the relevant chips have enough memory to do their task. If not, it would be simple for a rival to come out with a chip which had more memory for a slightly higher cost and eat the others' lunch. I know it is fashionable to assume that mainstream audio designers and chip manufacturers are simply incompetent, and of course they don't get everything right, but I think we can assume that on such a simple issue with such a simple solution they have done their sums correctly.
The low frequency performance of the motor is set by the PLL locked to the crystal clock. The high frequency performance is set by mechanical inertia from angular momentum. All that is left is mid-frequency for the FIFO buffer to handle.
The point that I want to make is that in 1990's the memory and smart memory controllers where expensive. So the CD transport was designed with bare minimum of RAM and minimal error correction/FIFO buffering.
Now, 20 years latter, it would make sense to use some bigger buffering, smarter algorithms, maybe dual-port memory, not the regular one, but there are no CD/DVD new controller chips to do that.
All of them are old designs.
A dedicated ARM with some 2-4MB of (dual-port) memory might be able to get rid of most/all that jitter... if it is done at the raw laser diode output data, controlling the motor PLL too, not latter on the chain.
Now, 20 years latter, it would make sense to use some bigger buffering, smarter algorithms, maybe dual-port memory, not the regular one, but there are no CD/DVD new controller chips to do that.
All of them are old designs.
A dedicated ARM with some 2-4MB of (dual-port) memory might be able to get rid of most/all that jitter... if it is done at the raw laser diode output data, controlling the motor PLL too, not latter on the chain.
Last edited:
No, memory was expensive in the 1980s. By the 90s it was cheap, but there is still no point in using more than is necessary.
Adopting your suggestion of many MB of memory etc. would not reduce jitter at all because the jitter comes from the clock. To reduce jitter you need a better clock: better circuit, more expensive crystal etc. Whether this is worth doing is a separate issue.
Adopting your suggestion of many MB of memory etc. would not reduce jitter at all because the jitter comes from the clock. To reduce jitter you need a better clock: better circuit, more expensive crystal etc. Whether this is worth doing is a separate issue.
Can I ask something basic ?
When the CD is removed from the player while playing (yes it's possible when no draw), is the time of remaining playback proportional to the buffer size ?
If it's the case, then my very ordinary player still plays for 25 seconds, around 4 Mb of data. Sonic's estimation looks possible.
When the CD is removed from the player while playing (yes it's possible when no draw), is the time of remaining playback proportional to the buffer size ?
If it's the case, then my very ordinary player still plays for 25 seconds, around 4 Mb of data. Sonic's estimation looks possible.
That's where we disagree. I think that the jitter from the clock it is way smaller than the one from the mechanics of the optical drive. Not inexisting, just like... 10 times smaller. So, bigger buffering for the pickup stage/motor drive control loop would be worth doing it.
Here's a link that may be of interest to some - although it is concerned with DVD writing - it gives some insight into the mechanics of spinning disks, data jitter & disk wobble http://dabramovitch.com/pubs/wob_pap_acc2k_talk.pdf
A nice diagram here of the logical parts of CD playback Technical articles-CD Player: How it works
I can see how confusion arises about the exact way CD decoders work with respect to clocks and timing, as many block diagrams are not explicit about what blocks are clocked by what clocks. Many more diagrams are downright vague, not showing anything about clocking at all.
That said, attached to this post is a diagram that is very explicit. The exact timing buses are shown, including directionality. The IC is a Sony CXD1167, a common decoder IC used in a wide array of brands of CD player. For clarity I have added highlighting to the diagram. The blocks highlighted in red are clocked by the clock recovered from the laser data only, and are synchronous with the speed of the CD. The blocks highlighted in blue are clocked by the crystal oscillator only, and are synchronous with the player's master clock. The blocks highlighted with both colours are partially clocked by both clock sources.
As can be seen in the diagram, everything before the RAM interface is clocked by the laser data's recovered clock. Everything after the RAM interface is clocked by the player's master clock. The motor control sub-system (the block labeled 'CLV Servo Control') works to keep those two clock signals almost exactly the same. This diagram is typical of any standard CD decoder IC. SoNic_real_one is right when he says that the frame buffer is very small, but it is still sufficient for the job. This lack of a large frame buffer is part of the reason early laser mechanisms are so impressive, the had to be for early servo systems to function. Nowadays RAM is cheap, so a very nice laser mechanism is no longer needed, and hence most modern laser mechanisms are hideous pieces of junk.
I hope this clears up a few misconceptions.
A few more things:
- I've never found a CD player that wasn't improved significantly by a low noise clock. They are a big upgrade, every bit as important as upgrades to the DAC, analog stage or power supply.
- Clocks are influenced by power supply noise. Every crystal oscillator is to some degree a voltage controlled oscillator (VCO), and hence its output frequency is dependent on its power supply voltage. Power supply noise will therefore directly cause phase noise. When you upgrade to a better clock some of the improvement will be due to the better oscillator, some of the improvement will be due to the cleaner supply provided to the oscillator.
- If you stop a CD in a (non portable) CD player with a big buffer it wont necessarily keep playing. Some are designed to cut playback if the difference between the laser data recovered clock and master clock becomes large.
That said, attached to this post is a diagram that is very explicit. The exact timing buses are shown, including directionality. The IC is a Sony CXD1167, a common decoder IC used in a wide array of brands of CD player. For clarity I have added highlighting to the diagram. The blocks highlighted in red are clocked by the clock recovered from the laser data only, and are synchronous with the speed of the CD. The blocks highlighted in blue are clocked by the crystal oscillator only, and are synchronous with the player's master clock. The blocks highlighted with both colours are partially clocked by both clock sources.
As can be seen in the diagram, everything before the RAM interface is clocked by the laser data's recovered clock. Everything after the RAM interface is clocked by the player's master clock. The motor control sub-system (the block labeled 'CLV Servo Control') works to keep those two clock signals almost exactly the same. This diagram is typical of any standard CD decoder IC. SoNic_real_one is right when he says that the frame buffer is very small, but it is still sufficient for the job. This lack of a large frame buffer is part of the reason early laser mechanisms are so impressive, the had to be for early servo systems to function. Nowadays RAM is cheap, so a very nice laser mechanism is no longer needed, and hence most modern laser mechanisms are hideous pieces of junk.
I hope this clears up a few misconceptions.
A few more things:
- I've never found a CD player that wasn't improved significantly by a low noise clock. They are a big upgrade, every bit as important as upgrades to the DAC, analog stage or power supply.
- Clocks are influenced by power supply noise. Every crystal oscillator is to some degree a voltage controlled oscillator (VCO), and hence its output frequency is dependent on its power supply voltage. Power supply noise will therefore directly cause phase noise. When you upgrade to a better clock some of the improvement will be due to the better oscillator, some of the improvement will be due to the cleaner supply provided to the oscillator.
- If you stop a CD in a (non portable) CD player with a big buffer it wont necessarily keep playing. Some are designed to cut playback if the difference between the laser data recovered clock and master clock becomes large.
Attachments
Last edited:
Indeed not - PSRR of 6dB or so (the switching threshold tracks the supply voltage) means the demands on the power supply are somewhat stringent in terms of noise.
No problem. I had been watching this thread for a while now, I decided it was time to weigh in.
Dead right. Not only that, but the oscillator must share its power supply with the rest of the IC (usually a digital filter or decoder), hardly a low noise situation. IC based oscillators can't be made to be very good though, so it's really not the fault of the IC designers or manufacturers.
Thanks, it's the approach to the Bridge St crossing of the Ferrymead estuary. It was badly damaged when I took this photo about a week after the September earthquake, and it's probably even worse now (after the more violent February earthquake). I've attached a photo of the wider scene, that's me on the far right.
Attachments
Back on topic, please.
Care to flesh this out a little? I would agree that most IC oscillators are made down to a price for volume but a claim that its not possible to make them good seems to me to be an extraordinary one. Any rationale for it?
Or are you in fact saying that in a design that begins with an existing IC-based oscillator its impossible to make the resulting design very good? In which case I've misread you.
To clarify, I said it was not possible to make them very good. Here is a quote from my favourite text on oscillators:
A discrete transistor circuit will usually give better performance than an IC circuit. This is because it is easier to control the crystal’s source and load resistances, the gain, and signal amplitude in a discrete transistor circuit. The discrete transistor amplifier usually has less time delay in it, as well, since it normally has only one or two transistors. On the other hand, oscillators using ICs are frequently cheaper when assembly labor costs are included. They also interface more easily with digital circuitry. And although their performance is generally less than that of a discrete transistor circuit, it is still better than what is needed for many types of digital circuitry.
- Robert J. Matthys, Crystal Oscillator Circuits (Revised Edition 1992)
This statement may not apply to some more modern ICs, as the state of the art has moved on, but is certainly applicable to conventional CD decoders, all of which are contemporary with the above text.
The quote also is talking about separate IC oscillators, and speaks of the limitations CMOS, TTL etc. It does not go into the additional limitations of IC oscillators integrated into larger ICs (which is what we are talking about). These have additional limitations, predominantly the share power supply.
In my opinion, there are three tiers of clock sources found in CD players (from worst to best):
- An IC oscillator integrated into one of the chipset ICs. Example; Philips 650, uses oscillator integrated into the SAA7220 digital filter IC.
- A separate IC oscillator. Example; Marantz CD16, uses IC oscillator made from a 74HC04 inverter IC.
- A discrete clock. No example since I can't think of a factory player using one, but plenty of DIY players do (including two of my own).
A discrete transistor circuit will usually give better performance than an IC circuit. This is because it is easier to control the crystal’s source and load resistances, the gain, and signal amplitude in a discrete transistor circuit. The discrete transistor amplifier usually has less time delay in it, as well, since it normally has only one or two transistors. On the other hand, oscillators using ICs are frequently cheaper when assembly labor costs are included. They also interface more easily with digital circuitry. And although their performance is generally less than that of a discrete transistor circuit, it is still better than what is needed for many types of digital circuitry.
- Robert J. Matthys, Crystal Oscillator Circuits (Revised Edition 1992)
This statement may not apply to some more modern ICs, as the state of the art has moved on, but is certainly applicable to conventional CD decoders, all of which are contemporary with the above text.
The quote also is talking about separate IC oscillators, and speaks of the limitations CMOS, TTL etc. It does not go into the additional limitations of IC oscillators integrated into larger ICs (which is what we are talking about). These have additional limitations, predominantly the share power supply.
In my opinion, there are three tiers of clock sources found in CD players (from worst to best):
- An IC oscillator integrated into one of the chipset ICs. Example; Philips 650, uses oscillator integrated into the SAA7220 digital filter IC.
- A separate IC oscillator. Example; Marantz CD16, uses IC oscillator made from a 74HC04 inverter IC.
- A discrete clock. No example since I can't think of a factory player using one, but plenty of DIY players do (including two of my own).
Fair enough
In that quote Matthys seems to be equating 'IC circuit' with 'digital IC circuit'. I see no reason that a suitable analog IC couldn't be used in a very good oscillator. Digital certainly is compromised when dealing with what's essentially an analog signal.
I broadly agree but ISTM that 'discrete' is a red-herring. What makes the oscillator very good is its designed as an analog circuit rather than as a digital one. IC vs discrete is a distraction.
Yes, you're right, that was my meaning also. I'm aware that some do exist, but I've never used one or seen one used as a clock for this application. I don't count a comparator being used after an oscillator as a wave shaper / level shifter as being part of the oscillator, but I am aware of circuits that use opamps or comparators (both ICs) as a genuine, integral part of the oscillator. My comments don't apply to them.
Have you ever tried oscillators with analog ICs? I'm certainly not biased against them, I'd be curious to see how they perform.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.