Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Removing CD drive jitter via buffering (Read 13001 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Removing CD drive jitter via buffering

Years ago (July 1996), Stereophile reviewed the Genesis Technologies Digital Lens . It was essentially a data buffer that would supposedly "eliminate" digital-audio data jitter.
Is an active, software-based (and/or combination software/hardware-based) solution available today for end-users -- possibly, e.g., a plug-in for Winamp or Foobar or WMP. WMP v.9 and up can decode HDCD "live" (i.e. actively, as the CD plays in real time; though I don't think there is that much activity going on in this case)? So, I'm wondering if plug-ins exist for it or other audio-player programs that can actively buffer playback performing jitter-reduction and other data tweaks?

Removing CD drive jitter via buffering

Reply #1 –
Audio data jitter only depends on the DAC clock. If a software/hardware player's internal buffer underflows, it will not begin to jitter, but it will produce drop outs or other evil things.

Removing CD drive jitter via buffering

Reply #2 –
I think that, in the case of external hifi DAC-units, surround amplifiers with spdif input etc, the phenomenon of spdif circuitry is surrounded by a lot of myths, not least backed by hardware manufacturers themselves.

Logically, all clocks drift somewhat.

Logically, when two units are exchanging a realtime stream of samples, the playback can be master-clocked by the source or the destination.

Since spdif lacks a return channel, logically, the destination (DAC) cannot tell the source (eg CD-drive) to speedup or slowdown.

A reasonable designed DAC-unit with spdif would use PLL or similar circuitry on its spdif input along with a buffer and possibly local clock to:
1. Supress short-time variations in re-gained clock-estimate
2. Allow low-frequency (even "DC") deviation in clock

The amount of HF jitter suppression and "cutoff-point" between jitter passband and stop-band should largely be a design-issue of price/complexity and ergonomy (waiting 2 minutes for a buffer to fill or PLL to lock is cumbersome).

1. Is necessary to avoid high-frequency jitter that the ear is quite sensitive to.
2. Is necessary so as to not have buffer underrun or overrun. Fortunately, the ear is quite forgiving when it comes to low-freq jitter (think about the wow & flutter values found in analog equipment, often priced among audiophiles for its high-quality sound).

Think about the price of memory today. Even a second of 44100 samples of 16bit stereo can be purchased at very low cost. At any reasonable clock-drift and jitter-level, a properly recovered sample-sequence could be fed into that buffer and played back at the rate of a local crystal. If one implemented feedback so that 1/3 full buffer resulted in a few ppm reduced playback-rate and 2/3 full buffer resulted in a few ppm increased playback rate, one would still have incredibly low frequency and amplitude (thereby hopefully audibility) of jitter compared to drifting analog gear. I am just thinking out loud, I am sure that someone with more insight could argue for more complex (and "cost vs quality"-optimal) regimes.

What is really missing is good measurements of eg DAC units in terms of jitter frequency/amplitude supression from input spdif to analog output. This would also show up in a system-wide thd+n measurement. Also, good double-blind listening tests proving that units with low jitter sounds better than units with higher jitter (or even tests estimating subject sensitivity to different jitter frequency/amplitude stimuli, coupled to measurements of hifi gear).

-k

Removing CD drive jitter via buffering

Reply #3 –
Any reasonable DAC reclocks the data. Transmission jitter is eliminated. An additional buffering prior to the DAC would be useless. Only the DAC clock's jitter can effect the output; in any decent equipment that is negligent.

Removing CD drive jitter via buffering

Reply #4 –
Quote from: AndyH-ha on
Any reasonable DAC reclocks the data. Transmission jitter is eliminated. An additional buffering prior to the DAC would be useless. Only the DAC clock's jitter can effect the output; in any decent equipment that is negligent.

That is in fact how it should be, there are however designs where the DAC clock (sampling rate that is) is simply derived from the S/PDIF-receiver. Depending on the quality of the S/PDIF-connection (like the
cheap optical TORX and TOTX) , any jitter generated there will have it's effect on the output. Surely
not anything close to a high-end design, but a cost-saver :-)
The mentioned digital lens seems to be a design where this is taken into account, i.e. read the data, buffer/store it and do output with high-precision, internally generated clock(s).
It won't be possible to do something similar in the PC environment, since you'll have no control
on the clock generation of whatever device you use for playback. So no Winamp or whatever plugin can
do anything about jitter, I'm afraid 

Removing CD drive jitter via buffering

Reply #5 –
The lack of ability to stick some compensator on the output of Winamp, WMP, etc. is still irrelevant. If you are using a decent soundcard or outboard DAC, there isn't a problem to correct, they will reclock properly. If you are playing form hard disk,there isn't a jitter problem to correct anyway. If you are playing a CD in the computer's CD drive, how are you going to get it to act without buffering? Any drive jitter is eliminated before the data gets to the software player.

Removing CD drive jitter via buffering

Reply #6 –
Quote from: mcbear on
It won't be possible to do something similar in the PC environment, since you'll have no control
on the clock generation of whatever device you use for playback. So no Winamp or whatever plugin can
do anything about jitter, I'm afraid  :)


Yup. This was noted in the article, too:

"The Lens suffers from one drawback inherent in all outboard jitter boxes: It must convert its jitter-free output into the S/PDIF or AES/EBU format to drive your digital processor. By putting the audio data back in S/PDIF, transmitting it down a cable, and recovering the clock with a PLL in your digital processor, jitter will be re-introduced. The jitter in your digital processor may be lower in amplitude and have a cleaner spectrum with the Lens, but it will still have some interface jitter as well as the intrinsic jitter of the digital processor's input receiver. Audio Alchemy's I2S bus alleviates this dilemma, but it works only with Audio Alchemy processors. "

Given this...

I thought that an I2S connection (via PCI bus ?) would allow the PC to bypass the sound-card's built-in oscillator (and/or (re)clocking components) and, therefore, directly enter the audio-card's DAC (if the DAC chip has an I2S input to begin with; and, then, if and only if the DAC chip can somehow internally turn off the audio-card oscillator signal input)? Not sure where the master oscillation signal would come from, though?! I used work in the manuf. industry where robots/machines would operate from virtual clocks. Not sure how accurate these can be made in comparison to better hardware-based (low-jitter) crystal oscillators.

References:

http://en.wikipedia.org/wiki/I%C2%B2S
http://www.anthemav.com/OldSitev1/pdf/i2Srev1.pdf
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
http://www.lessloss.com/faq.html

Removing CD drive jitter via buffering

Reply #7 –
Quote from: AndyH-ha on
If you are playing form hard disk,there isn't a jitter problem to correct anyway.


But isn't the hard-drive's digital data stream ulimately going to get routed the same way as the CD drive? Hence, it too is re-clocked via the audio-card's oscillator/clock circuit?

Unless it goes some other route, e.g. the aforementioned I2S.

Removing CD drive jitter via buffering

Reply #8 –
Quote from: hollowman on
Not sure where the master oscillation signal would come from, though?!

That is the main point. As long as everything is driven by one clock, jitter depends only on quality of that clock source. But, when you have to interconnect devices, problem arises. Digital jitter can never be completely eliminated, only kept under acceptable (correctable) amount. Recording studios have a dedicated equipment like master clock sources and clock recovery for digital interfaces to cope with jitter and synchronisation problems.
If age or weaknes doe prohibyte bloudletting you must use boxing

Removing CD drive jitter via buffering

Reply #9 –
Quote from: eevan on
Quote from: hollowman on

Not sure where the master oscillation signal would come from, though?!

That is the main point. As long as everything is driven by one clock, jitter depends only on quality of that clock source. But, when you have to interconnect devices, problem arises. Digital jitter can never be completely eliminated, only kept under acceptable (correctable) amount. Recording studios have a dedicated equipment like master clock sources and clock recovery for digital interfaces to cope with jitter and synchronisation problems.


It's important that the A/D end remain as jitter-free (and linear) as possible -- especially during he orig recording session(s) -- because that's something that pretty much gets set in stone once completed.

BTW, there are "audiophile" companies -- like dcs -- that offer these gizmos you noted, for both professionals and consumers (uh ...with deep pockets, that is). But how many folks can afford this $K gear?!

Removing CD drive jitter via buffering

Reply #10 –
Quote from: hollowman on
It's important that the A/D end remain as jitter-free (and linear) as possible -- especially during he orig recording session(s) -- because that's something that pretty much gets set in stone once completed.

I agree with you on that. There is no point in correcting jitter if the damage is done in the recording and/or production sessions.

Speaking of "audiophile" gismos, I certainly cannot afford them 
If age or weaknes doe prohibyte bloudletting you must use boxing

Removing CD drive jitter via buffering

Reply #11 –
Quote from: hollowman on
I thought that an I2S connection (via PCI bus ?)

I2S is a bus and not a connection, it cannot go "via PCI". As for the rest of your suggestion,
I find it very unrealistic.

Removing CD drive jitter via buffering

Reply #12 –
Quote from: hollowman on
Is an active, software-based (and/or combination software/hardware-based) solution available today for end-users -- possibly, e.g., a plug-in for Winamp or Foobar or WMP. WMP v.9 and up can decode HDCD "live" (i.e. actively, as the CD plays in real time; though I don't think there is that much activity going on in this case)? So, I'm wondering if plug-ins exist for it or other audio-player programs that can actively buffer playback performing jitter-reduction and other data tweaks?

Computer media players always use a buffer if they perform DAE (digital audio extraction) from a CD.

They get the data in chunks from the CD (at a rate faster than is needed for playback), put them in a buffer in RAM, tie them perfectly together, and send the buffer to the sound system.

Because of this, they perform better than a hardware CD player that lacks a buffer because they're more fault tolerant; since they read the CD faster than playback speed (1x), they can re-read the same chunk if there was an error. How good the error-correction is depends on the program of course.

The above only applies when actually doing DAE. "Old-style" 1x playback doesn't use a buffer.

Removing CD drive jitter via buffering

Reply #13 –
Quote from: hollowman on
Quote from: mcbear on

It won't be possible to do something similar in the PC environment, since you'll have no control
on the clock generation of whatever device you use for playback. So no Winamp or whatever plugin can
do anything about jitter, I'm afraid 


Yup. This was noted in the article, too:

"The Lens suffers from one drawback inherent in all outboard jitter boxes: It must convert its jitter-free output into the S/PDIF or AES/EBU format to drive your digital processor. By putting the audio data back in S/PDIF, transmitting it down a cable, and recovering the clock with a PLL in your digital processor, jitter will be re-introduced. The jitter in your digital processor may be lower in amplitude and have a cleaner spectrum with the Lens, but it will still have some interface jitter as well as the intrinsic jitter of the digital processor's input receiver. Audio Alchemy's I2S bus alleviates this dilemma, but it works only with Audio Alchemy processors. "

Given this...

I thought that an I2S connection (via PCI bus ?) would allow the PC to bypass the sound-card's built-in oscillator (and/or (re)clocking components) and, therefore, directly enter the audio-card's DAC (if the DAC chip has an I2S input to begin with; and, then, if and only if the DAC chip can somehow internally turn off the audio-card oscillator signal input)? Not sure where the master oscillation signal would come from, though?! I used work in the manuf. industry where robots/machines would operate from virtual clocks. Not sure how accurate these can be made in comparison to better hardware-based (low-jitter) crystal oscillators.

References:

http://en.wikipedia.org/wiki/I%C2%B2S
http://www.anthemav.com/OldSitev1/pdf/i2Srev1.pdf
http://www.nxp.com/acrobat_download/various/I2SBUS.pdf
http://www.lessloss.com/faq.html



I2S is just a bus used on some cards, DAPs, etc.  Generally what will happen is the data is sent across the PCI bus in packets, the packets are buffered, and then loaded across the I2S bus to the DAC.  Its probably also buffered by the DAC as well.

Removing CD drive jitter via buffering

Reply #14 –
Quote from: Mike Giacomelli on
I2S is just a bus used on some cards, DAPs, etc.  Generally what will happen is the data is sent across the PCI bus in packets, the packets are buffered, and then loaded across the I2S bus to the DAC.  Its probably also buffered by the DAC as well.

Most DACs will probably being fed their data by I2S, which is a three wire bus (data,  word select clock ( sampling frequency, to diffentiate beetween L and R) and a serial clock (usually 32 x fs)). The data is being
clocked serial "into" the DACs, and you can imagine, that with a poor clock generation you will suffer
from the same problems as with any other data connection.
The SPDIF-transceiver chips are often working with I2S-in/out as well btw.