In, http://www.tc.umn.edu/~erick205/Papers/pap...html#principles (http://www.tc.umn.edu/~erick205/Papers/paper.html#principles) we can read about RAM buffers :
This process is referred to as timebase correction and as stated before, any quality piece of equipment will implement it.
That has been the ritual answer to jitter concerns since I'm on the Internet.
But... if "any quality piece of equipment will implement it", then some non-quality pieces of equipment don't implement it. My question is : which ones ?
The statement "quality piece of equipment" is completely subjective and doesn't give any information. For my grandfather, a "quality" CD reader will be a portable radio-cassette-CD-speakers combo for 100 $ in the supermarket. The "non-quality" one will be the Fisher-Price toy for children from 3 to 7.
For an audiophile friend, the "quality" CD player will be the 25,000 $ Wadia CD Transport+DAC, while any player under 1,500 $ is just worthless crap.
So, do a 200 $ CD Player always have a RAM buffer ? Or is it not considered a quality piece of equipment ? What about a 300 $ CD Player from 1990 ?
Since it's the cheapest thing, I can't imagine any CD-player not having a simple FIFO-buffer IC.
Since it's not random accessible, I guess it's not properly called a RAM buffer. But it serves the same purpose, right?
All CD players contain buffer memory between the EFM code demodulator (basically just a lookup table) and the CIRC decoder. It's this very buffer that is monitored to control the disc's rotation speed and ensure a constant linear velocity.
This linear velocity is constantly being tweaked to ensure that the buffer never overflows or is ever starved for data. Don't confuse CLV and the disc's constantly decreasing rotational speed - the rotational speed winds down to maintain CLV (with appropriate buffer-driven adjustements).
As far as jitter at the DAC stage is concerned, there isn't any, save for the jitter in the master clock. No amount of buffering will help that. Each stage from the CIRC decoder to the DAC filter is slaved and synchronized to the chipset's master clock (which has an arithmetic relationship with Fs).
When Philips (Signetics) was pumping out 1X and 4X 16-bit CD chipsets in the mid-80s, their databooks had some fairly good application info with plenty of block diagrams. I'll see if I can't dig one up at work after the weekend...
Edit: added paragraph on Fs jitter
As far as jitter at the DAC stage is concerned, there isn't any, save for the jitter in the master clock. No amount of buffering will help that. Each stage from the CIRC decoder to the DAC filter is slaved and synchronized to the chipset's master clock (which has an arithmetic relationship with Fs).
Please correct me if I'm wrong. I'm straying a little off-topic here perhaps, but eventually hopefully covering what Pio2001 asks also.
With external bitstream feed, the master clock (from the perspective of the DA circuit) can be 1) the incoming bitstream's (when using SPDIF) original master clock generator OR 2) the master clock that is near the DAC itself (creating a new reference clock for the DAC, rather than using the clock from the incoming stream).
In many (if not most) cheap receivers, the DAC is slaved to the incoming (SPDIF) bitstream clock. The jitter contained in that signal will not be rejected and will most likely become part of the DA-converted signal's noisefloor (if random and not data induced).
In some receivers (this can be generalised to some external DACs and CD players) the input bitstream to DAC is buffered / jitter attenuated (there is a trade-off between attenuation frequency and power) and signal is fed to the DAC using a new hopefully more stable reference clock with diminished jitter levels.
An example of this aproach is the Chord DAC64 external DAC:
http://www.stereophile.com/printarchives.cgi?624:6 (http://www.stereophile.com/printarchives.cgi?624:6)
I don't want to debate the goodness/badness of that unit. Just pointing it out as an example of a dedicated RAM buffer for jitter attenuation.
Now, back to Pio2001's original question:
Yes, even simple/cheap cd-players contain a simple FIFO buffer.
Does this mean that their output does not contain jitter or that their internal DA conversion is immune to jitter?
No it does not. Jitter in DA stage is often linked to poor clock (deviation can be measured in hundreds of nanoseconds rather than hundreds of picoseconds), inadequate power filtering (e.g. power available to different parts modulates with the input data) and some other issues that can be avoided with a little bit more careful (and usually a little bit more expensive) electronics.
Does this mean such jitter in cheaper cd players is audible (now just talking about jitter, not I/V conversion, op amps and the analog stage after DAC in general)?
Somewhat debated area. Julian Dunn (in his Jitter Theory App Notes for Audiotech) has discussed the audibility of jitter at various levels using various signals.
Does it mean that the cheap cd-player can be used as a reference quality cd transport (assuming it does the disc reading / error correction properly) when combined with a superior jitter attenuation DAC?
To my knowledge, yes.
regards,
Halcyon
Pio,
I agree with the importance of your question: like most answers which suggest that digital audio "is basically perfect in any decent equipment", people who give these answers don't really understand the truth of it.
Let's assume the incoming audio data has loads of jitter on it, or the clock can't be recovered with a decent degree of stability. Now, the ideal answer is to dump the clock and re-clock it. But there's a problem: the new clock can't be completely independent of the original one. If it's too fast, then eventually you'll be wanting to output the next sample before it's even arrived. If it's too slow, then eventually the buffer memory will overflow.
So, it's clear that, in whatever system we have, even the re-buffered and re-clocked digital audio data MUST be synchronised, in some way and at some level, with the original, jittery data.
This means that the new clock will always be a filtered version of the original one. In a simple FIFO buffer, only the highest jitter frequencies are smoothed out. In a PLL system with a small amount of memory, lower jitter frequencies can be removed. Incidentally, the greater the jitter rejection, the longer the PLL takes to lock to the incomming signal. I've used DACs that take 2-5 seconds to lock.
A system with a large memory buffer will reject all but the lowest frequency components of any jitter (say, a few Hz at most, letting nothing higher through onto the output).
I don't know how many modern DACs use these technologies. All the sound cards I've used seem to lock almost instantly, but they're not separate DACs. The old Sony DAC I had at uni locked instantly. The nice Meridian DACs we had took maybe a second or too. An SME DAC we had took about 5 seconds.
It's an easy test though: turn the DAC and CD player on - start a CD playing, and then connect the SPDIF to the DAC - it'll give you a very rough idea of the technology inside the DAC. Though I wouldn't be 100% certain of this method! There may be methods to make a system appear to lock instantly, even though the lock is poor at first.
In one box CD players, you shouldn't need to de-jitter the signal - you should be running from a clean clock to start with, and pulling the data off disc as needed.
Cheers,
David.
So, do a 200 $ CD Player always have a RAM buffer ? Or is it not considered a quality piece of equipment ? What about a 300 $ CD Player from 1990 ?
Weren't we discussing jitter in a single-box $200 or $300 player from perhaps as recently as now or perhaps 10-15 years ago?
Does this mean that their output does not contain jitter or that their internal DA conversion is immune to jitter?
No it does not. Jitter in DA stage is often linked to poor clock (deviation can be measured in hundreds of nanoseconds rather than hundreds of picoseconds), inadequate power filtering (e.g. power available to different parts modulates with the input data) and some other issues that can be avoided with a little bit more careful (and usually a little bit more expensive) electronics.
Does this mean such jitter in cheaper cd players is audible (now just talking about jitter, not I/V conversion, op amps and the analog stage after DAC in general)?
Somewhat debated area. Julian Dunn (in his Jitter Theory App Notes for Audiotech) has discussed the audibility of jitter at various levels using various signals.
I think a quick bit bit of clarification on clock jitter and DAC performance might be in order. The switched cap sigma delta architecture does a nice job of providing quite a bit of immunity to master clock jitter, so it's not uncommon to see DACs over the past few years boasting 100-500psec jitter figures, assuming a decent stable clock. Some current PLLDACs boast sub-100psec jitter figures with a clock async to the data stream.
Can people hear that? If they CAN, then they would probably benefit from the likes of a product like the Auric Illuminator...
Edit: a bit of clarification...
Those are interesting side notes, F1Sushi.
Could you provide some links? By intuition, I'd say people shouldn't hear effects of less-than-nanoseconds-jitter, thus agreeing with you. But has that ever been verified by listening tests?
Those are interesting side notes, F1Sushi.
Could you provide some links? By intuition, I'd say people shouldn't hear effects of less-than-nanoseconds-jitter, thus agreeing with you. But has that ever been verified by listening tests?
Right off the bat, one of Analog Devices' current offerings, the AD1959, comes to mind...
http://www.analog.com/Analog_Root/productP...,AD1959,00.html (http://www.analog.com/Analog_Root/productPage/productHome/0,2121,AD1959,00.html)
I could throw in some more, but I think it would be a great exercise for folks to scour some current sigma-delta DAC datasheets and app-notes from the likes of Analog Device, TI/Burr-Brown, Crystal, National, etc, and get a feel for the current state of the art.
I spend half my work day doing this sort of thing, so on a holiday long weekend, forgive me if I don't jump to the occasion.
As for supporting such a statement with a listening test, I'll humbly lay back in the weeds and let someone else pioneer such an endeavor...
http://www.analog.com/Analog_Root/productP...,AD1959,00.html (http://www.analog.com/Analog_Root/productPage/productHome/0,2121,AD1959,00.html)
I could throw in some more, but I think it would be a great exercise for folks to scour some current sigma-delta DAC datasheets and app-notes from the likes of Analog Device, TI/Burr-Brown, Crystal, National, etc, and get a feel for the current state of the art.
OK, I'll see. Thanks.
I spend half my work day doing this sort of thing, so on a holiday long weekend, forgive me if I don't jump to the occasion.
You're forgiven, not forgotten... What kind of work are you doing (I tried your profile but it's empty like most)?
As for supporting such a statement with a listening test, I'll humbly lay back in the weeds and let someone else pioneer such an endeavor...
Sorry, but if you don't have any evident proof to say that it's inaudible, I really think you shouldn't make such statements. I mean, I too think that it's inaudible but as long as no persuasive reasoning can back my expectations, I'd rather follow Halcyon in saying it's a 'somewhat debated area.
Thanks, all of you for the answers.
There was a paper about jitter linked from here. I'll look for it when I'm home, but I remember that it was impossible to prove that the noise created by jitter in the ns range was below the threshold of audition.
As for supporting such a statement with a listening test, I'll humbly lay back in the weeds and let someone else pioneer such an endeavor...
Sorry, but if you don't have any evident proof to say that it's inaudible, I really think you shouldn't make such statements. I mean, I too think that it's inaudible but as long as no persuasive reasoning can back my expectations, I'd rather follow Halcyon in saying it's a 'somewhat debated area.
I agree wholeheartedly with your last statement, but bear in mind that I didn't actually say that it was inaudible - I instead made a joke in an effort to try and deflect any direct criticism regarding audibility...
I think I'm off on a technicality...
BTW, to answer your question - I'm a hardware engineer with a background in audio embedded systems (DSPs, codecs), networking interfaces, data acquisition hardware for time-domain sonar, and some motor control designs for robotics (PWM controllers & encoder feedback PID speed adjustment stuff).
Sorry, I completely lost the link. It was an old scientific paper about jitter, a PDF version of an AES article, I think.
There were plots of the maximum noise level intrduced by jitter, in the worst case, together with the human threshold of hearing.
I just remember that the jitter had to be insanely low in order to guarantee absolutely no audible noise in the worst possible conditions and at very loud listening levels (way less than 1 ns).
Sorry, I completely lost the link. It was an old scientific paper about jitter, a PDF version of an AES article, I think.
There were plots of the maximum noise level intrduced by jitter, in the worst case, together with the human threshold of hearing.
I just remember that the jitter had to be insanely low in order to guarantee absolutely no audible noise in the worst possible conditions and at very loud listening levels (way less than 1 ns).
Could this be it?
http://www.aesitalia.org/Materiale/archivi...heory%20(2).pdf (http://www.aesitalia.org/Materiale/archivio_documenti/AP%20-%20Jitter%20Theory%20(2).pdf)
No sorry, there was no color, it was all about jitter with more discussion about the possible audibility.
No sorry, there was no color, it was all about jitter with more discussion about the possible audibility.
There's a blurb on page 6 titled "Audibility Considerations" that references another paper and summarizes some practical research...
F1Sushi,
thanks for the clarification!
More musings on audibility of jitter from me personally:
As with anything in hearing, the amount of jitter that remains audible, depends on the jitter itself.
If results in random noise, it's much less perceptible than data induced jitter that modulates with the input signal and causes signal dependent distortion rather than (pseudo)random noise.
In both cases, the average levels of jitter can remain roughly the same, but other type of jitter (data induced input signal modulated jitter) remains more audible to the human hearing.
So, as with everything in engineering, jitter avoidance becomes a matter of engineering trade-offs. Work on the part that is considered/assumed to be the most audible and reduce that. Efforts elsewhere may not be worth the engineering efforts / costs involved.
best regards,
Halcyon
Sorry, I completely lost the link. It was an old scientific paper about jitter, a PDF version of an AES article, I think.
There were plots of the maximum noise level intrduced by jitter, in the worst case, together with the human threshold of hearing.
I just remember that the jitter had to be insanely low in order to guarantee absolutely no audible noise in the worst possible conditions and at very loud listening levels (way less than 1 ns).
Could this be it?
http://www.aesitalia.org/Materiale/archivi...heory%20(2).pdf (http://www.aesitalia.org/Materiale/archivio_documenti/AP%20-%20Jitter%20Theory%20(2).pdf)
Could this be it?
http://www.scalatech.co.uk/papers/aes93.pdf (http://www.scalatech.co.uk/papers/aes93.pdf)
Excellent paper and great bathroom reading, even if it wasn't it...
Those are interesting side notes, F1Sushi.
Could you provide some links? By intuition, I'd say people shouldn't hear effects of less-than-nanoseconds-jitter, thus agreeing with you. But has that ever been verified by listening tests?
Thought I'd follow up by offering some specs for a typical SPDIF recovery chip, in this case from Crystal. A current offering in SPDIF clock recovery and bitstream interface conversion for run-of-the-mill 3-wire DAC interfaces. Jitter spec on the recovered clock is 200psec typical.
http://www.cirrus.com/en/products/pro/detail/P54.html (http://www.cirrus.com/en/products/pro/detail/P54.html)
Could this be it?
http://www.scalatech.co.uk/papers/aes93.pdf (http://www.scalatech.co.uk/papers/aes93.pdf)
Yes, it might well have been this. Anyway, the informations given are the same. Thank you for finding it.
"Worst case 100% DAC jitter error resulting from a 22 kHz audio signal and a 18.5 kHz jitter. Only 20 ps peak jitter is required for audibility." (page 29)
I doubt that someone can play a 22 kHz sine into his speakers at 112 db and not fry them, and even if I use a 10,000 W soundsystem, I seldom listen to full scale 22 kHz sines.
The problem is that numbers don't guarantee that jitter is inaudible in all cases.
[deleted]
There is a device available from most high-end audio shops to correct jitter created by clocking differences between devices. I think it's called a Monarch DIP (Digital Processor).
Couldn't find any references to it on the web, except for an auction. How does it work? Assuming the input is SPDIF, and the output is likewise, I'm curious as to how it doesn't just create a new jittery SPDIF stream. If it's a different beast, my apologies in advance...
Found it - actually it's from Monarchy Audio, and it's output is SPDIF.
http://www.monarchyaudio.com/DIP.htm (http://www.monarchyaudio.com/DIP.htm)
This looks like nothing more than a decoder/encoder, which would seem to me at best like a placebo. The reviews weren' t too revealing, either, except to mention that the unit recovers the clock info from the incoming stream and encodes back to SPDIF...
"Everything improved---clarity, mid-range and treble smoothness, spatial resolution, focus, bass extension and tightness. Transients were cleaner, quicker. There was a more natural decay of instruments in time and space---and not by a small margin. All of the improvements were so obvious I didn't have to strain to hear them."
This reminds me of similar testimonials for the Auric Illuminator. Frankly, I just hope I'm missing something here...
Edit: Corrected a bad assumption.
Actually, from the description I'd suspect it does sample rate conversion. That is, from some sample rate to the same sample rate, but through the method of sample rate conversion.
Actually, from the description I'd suspect it does sample rate conversion. That is, from some sample rate to the same sample rate, but through the method of sample rate conversion.
Doesn't look like it, according to some of their info...
"The digital signals are decoded and processed, and any jitter is suppressed through the DIP. The three major functions of the DIP are:
1) Signal Conditioning
2) Signal Boosting
3) Signal Isolation (from In to Out)"
and
"The DIP 24/96 makes most D/A converter compatible with most DVD players. It does NOT change the sampling rates."
Seems to me that the final performance of a DAC would depend on the quality of the clock recovery in it's associated decoder PLL.
[deleted]
To clarify on the "Monarchy Audio" DIP Digital Processor issue, I merely mentioned it because I had seen it available (and installed in the shop systems) at local audiophile shops. I haven't auditioned the unit, ABX'd it, or anything like that. Just merely stating that it exists and is supposed to eliminate jitter. =)
I didn't really take your post as an endorsement - and thanks for mentioning it. I noticed one of these units went on eBay for $100 recently...
In the current (September!) issue of Hi-Fi News (UK magazine) there is mention of a device which is manufactured by these people:
http://www.jitter.de/ (http://www.jitter.de/)
The website answers a lot of the questions in this thread, though obviously they are trying to sell you their device.
The only objective error is here:
An ASRC (asynchronous sample rate converter) such as the AD1890 (go to the datasheet.pdf) from Analog Devices (a semiconductor manufacturer) is a great tool for converting sample rates.
If it had not been invented you would have to do a DA conversion and an AD reconversion with the required sample rate in order to accomplish a sample rate conversion. This would heavily degenerate your signal quality.
That's nonsense.
asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not. However, it's not relevant to the jitter discussion - it just shows they don't fully understand the area they are working in, or at least didn't feel the need to put fully correct information on their website.
They don't mention ABX testing - merely "subjective" results. I'm sure that won't please a few people here. However, the objective graphs and measurements are interesting.
If you have any interest in any of the questions in this thread, you should read through the whole website.
Cheers,
David.
The only objective error is here:
An ASRC (asynchronous sample rate converter) such as the AD1890 (go to the datasheet.pdf) from Analog Devices (a semiconductor manufacturer) is a great tool for converting sample rates.
If it had not been invented you would have to do a DA conversion and an AD reconversion with the required sample rate in order to accomplish a sample rate conversion. This would heavily degenerate your signal quality.
That's nonsense. asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not. However, it's not relevant to the jitter discussion - it just shows they don't fully understand the area they are working in, or at least didn't feel the need to put fully correct information on their website.
Thanks for the link, David. BTW, never underestimate the power and wisdom of marketing folks to squew, distort, and sometimes just plain misrepresent science and legitimate innovation.
Marketing: Where the rubber meets the sky.
2Bdecided,
do you know of studies/measurements analysing asynchronous sample rate conversion embedded jitter effects?
What I mean that if the incoming bitstream has different kinds of jitter (statistically random, uncorrelated with signal OR data correlated), then what kind of effects does this have on the output signal?
What I've read is the common "it becomes part of the noise floor" explanation (referring to jitter).
However, I'm not sure this would be the case with data correlated jitter.That is, jitter becoming random noise and not signal correlated distortion for example.
Do you have any information on that?
I haven't been able to find any.
I'd suspect that any (usu. small) increase in noise floor would be perceptible benign compared to data correlated distortion.
regards,
Halcyon
However, I'm not sure this would be the case with data correlated jitter.That is, jitter becoming random noise and not signal correlated distortion for example.
Just a side-note: Data-correlated jitter may be less and less of a problem as time goes on and PLLs improve. It is not uncommon now for PLLs to use only the incoming stream preamble (which is not data dependant) to maintain lock. Definitely still worth having a discussion on data-correlated jitter and it's effects, though...
You can always record an SPDIF output with an SB live, like this :
(http://perso.numericable.fr/laguill2/pictures/copiesanspertes.gif)
Beware that the loss seen here is not caused by embedded jitter, but by clock shift.
Another effect of clock shift : difference between a synchronous digital copy and an analog copy (obviously asynchronous) :
(http://perso.numericable.fr/laguill2/pictures/clockshift.gif)
They are in synch at the vertical bar, where they cancel each other.
Actually, from the description I'd suspect it does sample rate conversion. That is, from some sample rate to the same sample rate, but through the method of sample rate conversion.
Doesn't look like it, according to some of their info...
"...It does NOT change the sampling rates."
Yes, I noticed they said that. But on the introduction page they also say "The original clock retrieved from the transport is abandoned. " One of these statements must not totally be accurate, since they're not fully compatible, right?
So, I figured then, they meant by "not changing the sample rate" that it outputs the same nominal rate.
...That's nonsense. asynchronous SRCs embed the jitter into the output, but synchronous SRCs (all software non-realtime solutions are effectively synchronous) do not.
In it's most basic form, ASRC ofcourse embeds all jitter into the output. But I've been told that recent ICs doing ASRC manage quite high jitter attenuation before conversion. The upper limit to this is ofcourse imposed by the requirement that it be done in real-time; apart from that, it could theoretically be as precise as software conversion.
My take on it is that the statement about "abandoning the clock" is probably marketing-speak. One of the reviews goes into a bit more "detail"...
"Between the decoupling transformers, a high speed receiver/transmitter chip feeds a professional 'repeater' that demodulates the incoming S/PDIF signal into respective clock and data lines which are then separately re-encoded and clocked-out via a highly stable oscillator."
This same blurb was used in a couple reviews, and was probably produced by the manufacturer. Sounds like a classic decoder/encoder (no data manipulation, thank god) with a PLL ("highly stable oscillator") doing the dirty work. I certainly doubt that they would attempt any SRC - I really think this is just a re-clocker (remember their "conditioning/boosting/isolation" function description) which they recommend placing no more than a few feet away from the receiver. The PLL is the "conditioner", the line driver is the "booster", and the decoupling transformer is the "isolator".
Thoughts?
Edit: corrected "decoder/encoder", was "encoder/decoder"
Thoughts?
Well, I've only one further thought on this: how can people buy this product when it has such a fishy website? There's a lot of marketing blabla but so little real information, that it leaves us to guess what we're buying there. And apart from that, they never read more than a very basic HTML primer it seems (mildly wandering off-topic here...).
I suppose you're right about it not being a SRC. I didn't click through to the reviews at first.
Thoughts?
Well, I've only one further thought on this: how can people buy this product when it has such a fishy website?
What, the one I posted? www.jitter.de? Oh the answer's simple - they'll buy it because it's had a good review in a Hi-Fi magazine.
And everything on the site seems to be scientifically valid.
I just had an interesting email from Frank Klemm about ASRCs in movie playback. He says... (I'll remove it if it turns out that I wasn't supposed to forward this here!)
The sync engine has the task to display and play the decoded stuff.
There are three problems:
- the Video Card typically don't run with a multiple of (actually not
exact known) frame frequency
- The audio device typically don't run on the exact frequency which is
setup
- There are displacements between the time calculated from the
samplerate * samplecount and the time stamps.
Sources of this errors are:
- sound card and video card are derived from different quartz oscillators
- noone really cares about exact frequncies, a 100 Hz frame rate can be
99.253536 as well as 101.8378626 Hz, a 48000 Hz can be a 48662.06896 Hz
(SB 128 PCI)
- rounding and accumulated errors due to time quantization (typically
milliseconds)
- errors in A/V streams
- the typically view "It nearly works, why should I improve it"
- the typically "100 implementations and every is a little bit different"
Typically the video display engine has a simple job and only waits until the
time of a video timestamp is reached, then wait again until the CRT video
frame is finished and then switch to the next image.
The audio engine typically uses some called a "asyncronous sample rate
converter" or "Software PLL" which converts the audio stream to the sample
rate of the output device. This includes:
- estimation of the *real* sample rate of the output device
- estimation of the *real* sample rate of the input stream
- very smoothly adjusting small difference changes between these two frequencies
- adjusting medium difference changes between these two frequencies
- immediately adjusting large difference changes between these two frequencies
This is typically done by a control signal which is derived from the samples
in the sample fifo buffer. The sample count is normally lowpass filtered by%xact frequncies, a 100 Hz frame rate can be
99.253536 as well as 101.8378626 Hz, a 48000 Hz can be a 48662.06896 Hz
(SB 128 PCI)
- rounding and accumulated errors due to time quantization (typically
milliseconds)
- errors in A/V streams
- the typically view "It nearly works, why should I improve it"
- the typically "100 implementations and every is a little bit different"
Typically the video display engine has a simple job and only waits until the
time of a video timestamp is reached, then wait again until the CRT video
frame is finished and then switch to the next image.
The audio engine typically uses some called a "asyncronous sample rate
converter" or "Software PLL" which converts the audio stream to the sample
rate of the output device. This includes:
- estimation of the *real* sample rate of the output device
- estimation of the *real* sample rate of the input stream
- very smoothly adjusting small difference changes between these two frequencies
- adjusting medium difference changes between these two frequencies
- immediately adjusting large difference changes between these two frequencies
This is typically done by a control signal which is derived from the samples
in the sample fifo buffer. The sample count is normally lowpass filtered by
three ... five saturating lowpasses.
filter_effect = function ( lowpass_filtered_signal - input_signal)
lowpass_filtered_signal *= ( 1 - filter_effect )
lowpass_filtered_signal += filter_effect * input_signal
function (x) may be something like:
function (x) = ( x*x ) / (1 + x*x)
This suppresses high frequency jitter which may be audible.
--
Frank Klemm
Cheers,
David.
Thoughts?
Well, I've only one further thought on this: how can people buy this product when it has such a fishy website?
What, the one I posted? www.jitter.de? Oh the answer's simple - they'll buy it because it's had a good review in a Hi-Fi magazine.
Oops - no, it was for this product...but the same magazine review endorsement psychology no doubt still applies.
http://www.monarchyaudio.com/DIP.htm (http://www.monarchyaudio.com/DIP.htm)
This thread confirms a couple of opinions i have since quite some time now :
1. A well tuned CD player, with drive speed controlled by the DAC timer/buffer does always ( say, in most cases ) sound better then external drive / DAC combo's, however expensive they might be
2. SPDIF sucks in terms of preserving highest possible quality ( its practical, easy to handle, but thats about it )
3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing ....
...
3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing ....
Yes, this is something I really don't understand about "high-end" hardware brands. Such two-way traffic not only provides best results, but it is also much cheaper and easier to design. Since it (presumably) sounds better, they could still sell it at the same pricepoint at which transports-with-ultra-hyper-cool-stabilized-clocks and DACs-with-four-stages-of-PLL are sold nowadays, while saving themselves a lot of hassle.
Shhh... don't tell them. It's reserved for the professional studio market
regards,
Halcyon
Just came across this link, which raises several topics brought up over the past few posts, including
1. SPDIF reclocking (confirmed my fears).
2. I2S (3-wire) clocking scheme for separates.
3. DAC clock sourced timing for separates (my preference, as it closely emulates the 1-box architecture from a clock-distribution perspective).
http://www.republika.pl/mparvi/digital.htm (http://www.republika.pl/mparvi/digital.htm)
Not sure about the source, but I can't argue with the facts presented. Perhaps the presented state of the art wrt decoder jitter attenuation is a bit dated, but I think we would all sleep better if integrated PLLs were a bit better at suppressing LF jitter...
This thread should be in the FAQ!
Cheers,
David.
Here's a Monarchy Audio DIP on a chip:
http://www.cirrus.com/en/products/pro/detail/P51.html (http://www.cirrus.com/en/products/pro/detail/P51.html)
Just decode the incoming AES3 stream, recover and dejitter the clock, and use same to drive the AES3 output interface.
The 3-wire I2S interfaces are gravy...
This thread confirms a couple of opinions i have since quite some time now :
1. A well tuned CD player, with drive speed controlled by the DAC timer/buffer does always ( say, in most cases ) sound better then external drive / DAC combo's, however expensive they might be
2. SPDIF sucks in terms of preserving highest possible quality ( its practical, easy to handle, but thats about it )
3. MISSION people knew what they were doing when inventing a new digital interface ( no SPDIF on these devices ) for their hi-quality CD drive / DAC combo's , with good old handshake signals to sync the timing ....
I did some simple pen and paper exercise, and this is what I found out:
Let's say our CD-player reads twice as slow as our DAC reads from FIFO buffer.
Datastream is a,b,c,d bits)
clock
CD__DAC__BUFFER (3bit)
1___Pause__000
2_________00a
3_________0ba
4_________cba
5____1 ____0cb
- ____2____ 00c
6____3 _____00d
-____4_____000
7____5 _____000 (bit e just makes it!)
-____6_____000 underrun!
Let's say our CD-player reads twice as fast as our DAC reads from FIFO buffer.
Datastream is a,b,c bits. We have 4 bit's FIFO
clock
CD__DAC_ BUFFER (4bit)
1___Pause_000
2________000a
3________00ba
4________0cba
5___1____0dcb
6________edcb
7___2____fedc
8________buffer overrun!
Ok, so what, no CD player works this way. They're not that stupid.
BUT.. say the clock in the CD-player would be 0.00001% slower or faster,
eventually it would either underrun or overrun. Even if it's unstable being sometimes faster sometimes slower(jitter) it would have a meantime that is either slower or faster, and that will also eventually overrun/underrun the buffer. So what to do?, well.. two way communication would be nice. I guess most CD-player adapt their reading speed with regards to how full their FIFO buffer is.
How big is this problem in real life?, no idea. I think I'll buy an external USB DAC to my computer when there is a good one available.
You're pointing out the exact reason why a two box transport/DAC combo has jitter problems: you can't afford buffer underruns, since even the most unmusical listener will hear that.
So, when an spdif link is used, DACs don't use their own free running clock; instead, they have a clock that can follow the transport's clock. This is an ugly process: the perfect square wave that the transport's clock may well have is lost in the long way to the DAC; there's non-ideal cabling, noise, intermodulation between data and clock signals, and lots more. The DAC then, is not following a perfect clock at all!
So you see, 'in real life', buffer over/underruns are not a big problem. But precluding those problems causes this other problem.
As to one box cd-players: the rate at which their transport reads is controlled by the same clock signal as the DA-rate. By principle, the fifo will always be filled then. The purpose of a fifo here, isn't in the first place to buffer reading speed variations, but to cope with the fact that bits don't all have the exact same length on the CD surface.
As 2Bdecided explained, this is only valid for cheap DACs. Good DACs filters the incoming jitter in such a way that the master clock is the DAC's one and not the CD Player's one.
The trick is that the DAC's master clock is allowed to drift very slowly in order to compensate for buffer variations. Ideally the buffer is 50 % full. If it becomes >50% full, the master clock is speeded up very smoothly in order to go back to 50%, and if it becomes less than 50% full, the clock is slowed down.
In conclusion, we still don't know which kind of players have a variable clock in order to lowpass the incoming jitter, and which ones directly slave themselves to the incoming stream, but we have another problem in addition, we don't even know if there is an audible difference between the two technologies (http://perso.numericable.fr/laguill2/smileys/bonk.gif).
By the way, I don't think that the time spent by a DAC to output audio after a digital stream is fed gives any useful indication. For example the Sony DTC 55ES is a DAT deck. The DAC takes from 0.5 to 1.0 seconds to output audio after a sample rate change. But the device produce an audible clic when it's done. This clic comes from an internal switch that turns the analog output on/off. The same clic is heard 4 seconds after the device is turned on, because a delay is set at startup, before the outputs are enabled, exacly like for many power amplifiers.
Thus the time took by a DAC to output sound when a digital stream is plugged on might depend on the delay setup for the analog output muting, that can have nothing to do with the time needed to synchronize with the incoming stream, or I'd rather say, that is setup long enough for the digital stream to be in sync long before the analog output is unmuted. How much long before is up to the engineer who designed the circuitry.