This is strictly true. However, if the DAC clock source shares a PSU with the transport, or even if the DAC PSU is common with the clock source, there remains scope for variation in the clock which relates to either the transport servo, or the exact data pattern itself. Jitter is all in the isolation of the clock source PSU, if it's there at all, I think.
So when does jitter lead to errors. Should be obvious that if the peak jitter is more than a half clock cycle the next stage may be looking at the wrong bit.
Peak jitter is a bit higher than average or rms jitter. In a CD I would expect some jitter from noise but most of it from mechanical systems. So a sine approximation would be a good model. Now if the PLL were digital I would use a triangle wave approximation.
So if you are looking at the data straight from the CD it is read and then subjected to robust error correction. If you look at the data stream from the corrected data to the D/A converter often there is no additional error correction. So that would be a weak link.
That brings up the issue of in that chain how much jitter is acceptable. That is what I think Jan was looking at. As that issue is perception based there is no single answer.
If you are listening to loudspeakers in a normal room, you may only have a signal to noise ratio of 50 dB. If you have a monster system and live in a small town, you could have a 90 dB signal to noise ration. The next issue is noise to signal discrimination. You can add 20-60 dB for this.
So 16 bits should be fine for many. But more bits and less error would be needed for others. No magic, no hand waving just a bit of the basics.
Peak jitter is a bit higher than average or rms jitter. In a CD I would expect some jitter from noise but most of it from mechanical systems. So a sine approximation would be a good model. Now if the PLL were digital I would use a triangle wave approximation.
So if you are looking at the data straight from the CD it is read and then subjected to robust error correction. If you look at the data stream from the corrected data to the D/A converter often there is no additional error correction. So that would be a weak link.
That brings up the issue of in that chain how much jitter is acceptable. That is what I think Jan was looking at. As that issue is perception based there is no single answer.
If you are listening to loudspeakers in a normal room, you may only have a signal to noise ratio of 50 dB. If you have a monster system and live in a small town, you could have a 90 dB signal to noise ration. The next issue is noise to signal discrimination. You can add 20-60 dB for this.
So 16 bits should be fine for many. But more bits and less error would be needed for others. No magic, no hand waving just a bit of the basics.
Yes. Of course if you want to brave the hazards of a potentiometer,
you can use 20 to 50 ohms and take the signal off the wiper, which allows
offset and/or 2nd harmonic null.
I'm trying to figure out if your understanding is really this poor or if this is deliberate. I vote for the latter.
jitter problems are NOT about the bit being the wrong bit. There is no data integrity loss. What is the problem is the timing of the data delivery to the final d to a conversion. This causes an incorrect translation of the data to the analog signal. Its a timing error, period. (bad pun).
Alan
Alan
Close. It's the timing of the actual conversion. And that's controlled by the crystal clock. This is the ONLY place in the playback chain that jitter matters unless the system is so overwhelmingly bad that data is lost- and that manifests as skipping and pops, not sonic changes. As DF96 likes to say, this is only a problem with the very cheapest and the very most expensive units.
SY
Let me clear this up for you. I was referring to an external D/A. The internal D/A is driven by the corrected signal which is internally clock controlled. So with an internal D/A you have discrete time and discrete level.
For those folks improving the CD player with an external converter that again requires a PLL to receive the data.
So the theory says that an internal converter should be better. However most implementations do not achieve that.
The best would be a well isolated converter that gets data and clock signal.
I was talking about data stream jitter. Converter clock jitter is a different issue.
This has all been about data errors not the quality of the converter. I can see how the two issues get confused.
My analogy to digital and analog jitter would like like this. You can hand a sheet of music from one person to the next and as long as they can write music accurately every copy will be exactly the same, baring handwriting of course, and there could be a thousand continuous copies with not one difference at the end of the exact notes being recorded onto the paper copies. Now add timing in that a musician now has to play that written music and he has a metronome to set his timing of the piece. That metronome would set the jitter of the analog playback, the actual sound we hear is set by the clock, metronome variation that the music is played back to.
Now someone with pitch perfect hearing could transpose that musical event to paper and again the jitter, or metronome error would be gone, you are back to a note perfect written copy of the original written music, the digital, written copy is restored to perfection. Play it again and you introduce new jitter, metronome error that would disappear with the next written copy by that perfect pitch listener who would write it down once again.
Jitter can't be passed if we are only talking about playback clock jitter and re-encoding of the digital code.
Now someone with pitch perfect hearing could transpose that musical event to paper and again the jitter, or metronome error would be gone, you are back to a note perfect written copy of the original written music, the digital, written copy is restored to perfection. Play it again and you introduce new jitter, metronome error that would disappear with the next written copy by that perfect pitch listener who would write it down once again.
Jitter can't be passed if we are only talking about playback clock jitter and re-encoding of the digital code.
hase anyone bought and used these jitter test CD's??
Jitter in a Nutshell: "Whole Lotta Shakin' Goin' On"?
THx-RNMarsh
Jitter in a Nutshell: "Whole Lotta Shakin' Goin' On"?
THx-RNMarsh
I see that in the years since I've ever seen TAS (decades, maybe?), their traditional standards for technical writing are still in place.
Do you remember when Bascom King wrote about a big Jadis power amp and nearly showed measurements, while noting that the amplifier was oscillating some of the time? I met him in those days at CES, when he drew the short straw and had to man the Infinity room (which gave everyone terrible headaches if there for long---projection TV and very loud music, I think usually playing Top Gun). I mentioned the TAS article and he seemed genuinely defensive. It was not a very pleasant interaction, although I was not confrontational---maybe someone else had just been so.
Bascom does know how to design things though. I'd worked on some automotive amps with which he'd been involved. The tone in the TAS review was to some extent a confession of puzzlement, and I did appreciate his willingness to be that vulnerable.
Yes, I remember thinking at the time, "Why is he puzzled? It's an effects box and he likes the effect. No mystery."
Jadis amps are delightful examples of everything that was ever wrong with high end audio.
I can't believe people are having to resort to various analogies to explain jitter and why it only matters at conversion.
I mean, I can see those analogies being used for a young Hipster couple at Best Buy, but in here?
se
I mean, I can see those analogies being used for a young Hipster couple at Best Buy, but in here?
An externally hosted image should be here but it was not working when we last tested it.
se
Last edited:
So what? Clock at conversion. Nothing else (unless pathological). I know you understand this.
- Status
- Not open for further replies.