opaqueice;153839 Wrote: > OK, so we agree that loading it all into memory eliminates jitter > entirely. The next question is whether the Lavry (which I use as an > example because it's the only one I've read the white paper for) > accomplishes this as well. What they do is use a CPU to check the > state of the buffer. If it's getting full, they increase the speed of > the clock (which controls the output); if it's emptying out they > decrease it. This keeps the buffer around half full all the time. > They make this (tiny) adjustment every ten seconds or so for a typical > timing mismatch. > > Now, while it's possible (but implausible) that this adjustment process > could have an audible effect on the sound, it's still got nothing to do > with, and is totally independent of, input jitter. It depends only on > the difference in _average_ clock rates, not when each individual > rising edge arrives.
Well, that might be a semantic difference, because jitter is measured as an average, not regarding each individual rising edge. As the dCS whitepaper describes, we're now talking about "Signal-related timing error", not random "noise-related" jitter. The only reason why you'd have buffer overflow/underflow is because of a difference in the transport and DAC clocks, and this is essentially the same issue that is introduced by PLL's. The bottom line is if you have a system that uses two different clocks, there will be differences, and therefore jitter will be present. EDIT/ADDED: The remaining question is whether it is enough jitter to be audible. -- PhilNYC Sonic Spirits Inc. http://www.sonicspirits.com ------------------------------------------------------------------------ PhilNYC's Profile: http://forums.slimdevices.com/member.php?userid=837 View this thread: http://forums.slimdevices.com/showthread.php?t=29450 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
