Understanding Jitter in PC Audio

" if you use USB then it all comes down to the clock in the DAC."

Some DAC's have upsampling clocks in them, but many have no clock at all. NOS DAC's have no clock.

There are a handfull of very expensive DAC's that generate a local clock and allow you to use this, but only if the source has a word-clock input and can be synchronized to the local DAC clock using a word-clock cable.

Steve N.
Empirical Audio

"My Understanding is that in case of a HDD based transport, the File is converted into an Async format (Lossless) . This is then played via a PC/Mac and when given out as digital out, the clock that is synched to is the machines own clock (Am I right ?)"

The output from the PC, whether it is USB, Firewire or S/PDIF from a soundcard or Mac has the clock embedded. The clock is generated by the computer clock or by a local clock on the sound card.

The only time that the soundcard clock frequency can be influenced is if it has a word-clock input that synchronizes the soundcard clock. This does not reduce jitter however.

Lossless format is optional. There are many formats that can be stored on the computer hard drive or flash drive. They are all converted to the correct format for transmission on the interface, S/PDIF format for this interface, USB format for this interface etc.. The playback software, such as iTunes or Foobar does this transparently. If you have .wav, AIFF and FLAC files of the same track on the disc and you play them one after another, they will all be converted to the same identical data and format for transmission or transport.

The transport formats are different than the stored formats. Transmission of digital data is specific to each interface, USB, Firewire or S/PDIF. Once these are received, they are all eventually converted to either S/PDIF and then I2S or directly to I2S bus.

a) does this impact jitter of the Lossless file in anyway ? also what would the difference between an I2S and an USB interface be in this case as the clock is not really the original clock ?

Jitter is independent usually of the format that the data is stored.

As for the transport format, such as USB, the clock is embedded in the data and must be recovered at the receiving device if it uses Synchronous Adaptive mode. This usually requires a PLL.

I2S is not a native interface for a PC or Mac, so it must be generated from another interface, such as USB, Firewire or S/PDIF. I2S is the native interface for the D/A chip, so all interfaces must end-up converted to I2S.

I2S is not the original clock in the PC, but is synchronous to the original clock.

b) Can the original information without any timing errors be reconstructed from this using an external reclocker like the empirical audio device OR Monarchy ?

Reclockers like the Pace-Car 2 can generate a totally new clock which is synchronous or tracking to the original clock, but with lower jitter.

The original information is only data, not timing. The timing is only implied by the standard frequency that is used at recording time, when the analog data was converted to digital. If the A/D clock had jitter, then the record timing will be innacurate. This cannot be fixed once the data is stored as a digital recording. If the D/A clock has jitter, then the playback timing will be innacurate. This jitter can be minimized with reclockers, upsamplers etc..

c) If the clock is not present will an external DAC just assume the input to be as per its own clock. (If the rip were done by CDROM using the same clock freq as a DAc give any added benefit)

DAC's dont have clocks in general. The only clocks in typical DAC's are for upsampling. DAC's rely on the clock embedded in the incoming datastream, whether it is S/PDIF, AES, Toslink. DAC's recover the clock(s) using hardware. If the interface to the DAC is I2S, then the clocks are discrete so they drive the D/A directly without needing clock recovery.

Ripping has nothing to do with the timing accuracy of a data file. It is simply data. There is data and then there is the timing of when the data is presented to the D/A chip. This timing is not stored on the disk. Only the data is stored on the disk. The timing is recreated at playback time. No relationship to the music timing or beat.

Steve N.
Empirical Audio

"Shadorne
USB has no clock - it is an asynchronous protocol."

Actually, this depends on the USB protocol. All USB converters use Synchronous Adaptive mode, which uses the embedded clock in the data stream from the USB cable. It relies on the clock at the computer.

Steve N.
Empirical Audio

Arj wrote:
"If the industry could standardize on HDMI components to transmit native I2S, we could kill off the crappy optical and SPDIF connections we use now and virtually eliminate the need for expensive re-clockers (sorry about that part, Steve)."

I2S alone is not sufficient. First you must have a low-jitter signal. If there is already a lot of jitter, changing the bus to I2S will not fix this. It will still have the same jitter. Reclockers are still needed.

Steve N.
Empirical Audio

Mapman wrote:
"So in the case of jitter, once the clocking of the data is hosed, how practically does re-clocking it make it right again or at least better. What algorithm is used? Is it that the correct clocking is just implicit in the sample rate of the bitstream assuming all the original bits are transmitted? If so, why bother clocking data in these crazy digital audio systems in the first place?"

The data samples themselves have implicit in them the rate at which the recording samples were taken at record time. This is the standard, a perfect 44.1K samples per second for CD data. The reality is that the sample-rate at record time has jitter too, so it is not a perfect 44.1kHz. Recording studio equipment varies in quality and some A/D clocks are better than others. These sample inaccuracies at record time cannot be corrected. The samples are the samples, that's all you have.

The sample-rate inaccuracies at playback time on the other hand can be minimized. The sample-rate clock is part of the datastream only when the data is being transferred on playback, not when it is stored in RAM or on hard disk. It is the rate at which the sample data is transferred from one point to another, like from a Squeezebox to a DAC or from a Macbook Toslink to a DAC. Each tick of the clock transfers another bit from point A to point B. Without this clock, there would be no playback. The rate is set by the "source" device internal clock, such as the clock inside the Macbook or the clock inside the Squeezebox.

Reclockers goal is to throw away the incoming clock and totally replace it with a local oscillator at the same frequency. The problem is that frequency of the local clock will never be exactly the same as the frequency coming in unless the source clock is generated as a result of the reclocker local clock. This case is precisely what happens when you connect a word-clock cable from a reclocker to a Lynx Card for instance. The Lynx card adjusts its master clock to match the average frequency of the word-clock from the reclocker. Then, the average rate of the data from the source matches the average rate of data transfer of the reclocker output. If these match, then there is no data overrun, no lost bits, no drop-outs. I say "average data rate" because the actual data coming out of the reclocker does not match the incoming rate from clock to clock, only over a large number of clocks. This is what allows the reclocker to output a clock with lower jitter. The time interval between ticks of the reclocker output clock is more consistent than the time interval between ticks of the incoming stream clock. More consistent time interval equals lower jitter. Same thing.

Why reclock at all? Because jitter at the clocks of the D/A converter causes modulation of output analog signal from the D/A converter. This is distortion. This modulation is a function of both the magnitude of the jitter and the spectra of the jitter. This is one of the things that makes digital audio sound "digital" and not analog, along with sample rates that are not high enough.

The evidence of this is really obvious when you compare several DAC's to one another. With a high-jitter input signal, they all tend to sound radically different. With a low-jitter digital input signal, they all start sound very similar. Each DAC behaves a bit differently in the face of jitter, the simplest ones tending to sound the worst with high-jitter input and the best with low-jitter input.

Steve N.
Empirical Audio