Like most things, with FIFO queuing, the devil is in the details. I would argue that it's extremely difficult to achieve really low jitter (like my 7psec), when using a FIFO design, UNLESS the source is willing to throttle the data into the FIFO under the control of the FIFO (this is a "PULL" technique rather than a "PUSH" technique) or you are willing to live with out of spec oscillator frequencies.
If you are talking about a typical PUSH technique where the data is coming whether the FIFO is ready or not, then achieving really low jitter is very difficult. Here's why:
There are only three methods for making this work (avoiding FIFO overruns and underruns) and they all include methods to vary the Master Clock frequency:
1) pull the data from the FIFO output using a PLL controlled oscillator. This will sync with the input data flow and avoid overruns and underruns.
2) pull the data from the FIFO using an oscillator that can be "pulled" slightly off the nominal frequency, both higher and lower. This "bang-bang" system keeps the FIFO from overrunning by changing to a higher frequency and underruning by changing to a lower frequency.
3) pull the data from the FIFO using multiple clocks that are slightly above and below. The clock that is selected is based on whether the FIFO is trending to underrun or overrun at any point in time.
Steve N.
Empirical Audio
Aremt you forgetting that the data is the clock and the clock is the data, and the pll in detection is only used to set the sampling point. (I know, I have implemented self clocked schemes from scratch.)
If the pll gets out of sync, then you are 'dead meat', because the signal is either a logical 1 or 0. An unlocked pll doesn't allow data recovery. An imprecise sample will result in an error or not when coming directly off the media. A CD doesn't hav analog data where the sampling point might be important for accuracy beyond the simple 1 or 0. The sampling point accuracy only determines the reliability of the data. There isn't an in between for the data itself. If there is sampling point jitter, then there is a correct detection or not -- not an in-between. There CAN be a statistical liklihood of accuracy, but that is the only real 'percentage' associated with the data. This would be the digital equivalent of SNR.
Another thing, the electronic circuitry used to read the optical device needs pre-amplication, but that also resolves to a 1 or 0. During the actual detection process, some more stats might be done, and merge the details of the PLL with the analog result of the detection -- again, there has to be a resolution to 1 or zero for the data, and the clock comes along with it.
The clock on disk and the data-on-disk don't get out of sync, but if the sythesized clock from the PLL gets out of sync -- then it is an error. If the sampling point is off too far, then there is also an error. Jitter in the sampling point only increases the liklihood of error, not causing jitter in the resulting data.
So, here is what you have: data can be 1 or 0, the pll can be 'locked' or 'unlocked', and if achieving lock, the sampling point can be 'accurate enough', or 'inaccurate.' There is no 0.75 for the value, it is 0 or 1. The clock for the data does come from the pll (or the disk in reality), but the accuracy of the data sampling point doesn't result in a more or less accurate answer for that one bit, it only determines the likelihood of correctness. Now, there can be a relative likelihood of correctness, but we are not reading data that is statistically encoded, but rather the real 1 or 0 that had been recorded. (for analog laser disks, the statistics can produce video noise, but that kind of noise doesn't happen on audio discs unless it is so bad to cause an error.)
If you are talking about the pll/feedback loop for the data buffering, then that is also kept in sync as I had described before in another posting -- the rotation of the medium is logically very similar to a variable speed FIFO in its own right, and it is used to feed a data buffer fifo clocked by the data coming off the disk on one side, and the rock-stable system clock on the other side of the data buffer fifo. At that point, there is NO jitter other than the relatively rock-solid system clock.
PS: I am pretty sure that I didn't make this clear -- there are effectively two different PLLs (depending on implementation). There is the RAW data recovery PLL as most of my posting talks about -- it locks to the on-disk signal to almost something like a radio signal, except it is a series of pulses with a specific frequency and kind of pattern. (The simplest think like this is a Manchster encoded scheme -- Wiki probably describes that.) Also, there is a second 'phase lock', and that is for the rotational behavior of the drive. It helps to keep the higher level data rate correct, and the data FIFO full without overflowing. So, we have both the data signal (bit by bit), and the data rate (packets of some kind, might be bytes.) There might be a way of implementing both PLLS as the same, but the simplest implementation is to both synchronize TO the data on the disk, and synchronize the rotation to the required data clock out rate. The platter rotation can have a lot more timing slop than the data clock, and most likely the platter PLL runs more slowly than the data PLL. (AGAIN, it might be possible to merge the two somehow, but tightly tieing the raw data with the rotation might not be a good idea.) If you read about Manchester encoding, you can see generally how the clock and data can be integrated into the same stream.
John