USB vs. Toslink

[audioengr]

"AFAIK the number of clocks is not about having a "scatter-gun" spread around the target frequency, but to support multiple different encoding data rates (44.1kHz, 48kHz, 96kHz, 192kHz...)."

 

The same clock used for 96 is likely used for 192. There are likely multiple clocks for one SR range, at least 2. I believe this would be necessary or you would need terabytes of FIFO buffer in order to prevent overruns.

 

Steve N.

 

[noogle1]

you would need terabytes of FIFO buffer in order to prevent overruns

 

Isn't a 60-minute CD at FLAC quality (44.1k/16bit) only about 600Mbytes?

 

RAM is pretty cheap nowadays, and my instinct is that it is always better to fix issues in the digital domain than the analogue domain.

 

[Miska]

Sounds easy doesn't it? The BIG problem is that anything other than free-running oscillators have high jitter in comparison.

 

No, easy would be too easy and boring. But the idea is to have one high quality fixed frequency oscillator and derive multiple different frequencies based on it using clock synthesizer.

 

Good TCXO plus something like Xilinx Virtex 6 is a good combo for doing all kinds of fancy stuff.

 

[Miska]

I believe this would be necessary or you would need terabytes of FIFO buffer in order to prevent overruns.

 

Just for fun, calculate how long it takes to overrun a terabyte FIFO with something like 0.1% clock speed difference (which is fairly large)...

 

 

[audioengr]

"Isn't a 60-minute CD at FLAC quality (44.1k/16bit) only about 600Mbytes?"

 

Yes, but that doesnt help the computer audiophile. Playlists can go on all day long. Mine do...

 

Steve N.

 

[audioengr]

"Good TCXO plus something like Xilinx Virtex 6 is a good combo for doing all kinds of fancy stuff."

 

FPGA's are good for implementing complex circuits. Not so good for jitter however. I ALWAYS use discrete logic for this. This is why many of the USB interfaces dont sound that good IMO.

 

Steve N.

Empirical Audio

 

[audioengr]

Okay, so a Terabye was an exaggeration. However, if you have enough RAM to compensate for a long playlist, it would be large.

 

If the difference in sample-rate was 44.1kHz versus 44.15kHz, then the difference is ~3kBytes per second. In 8 hours of playing music, you would need about 100MBytes of memory to prevent overrun.

 

Steve N.

Empirical Audio

 

[Miska]

FPGA's are good for implementing complex circuits. Not so good for jitter however. I ALWAYS use discrete logic for this. This is why many of the USB interfaces dont sound that good IMO.

 

But discrete logic is not good for implementing complex logic and DSP which was the point here. And FPGAs don't generate jitter unless there's bad design. Gate propagation delays are well understood.

 

Making something which requires thousands of logic gates is not very feasible in discrete.

 

 

[noogle1]

Maybe I'm thick (!), but I still don't understand why jitter on the data input into a DAC matters if you're not generating the DAC clock from the data. In computing terms audio data rates are really slow, so if you're clocking the correct sequence of 0s and 1s into the DAC, what's the problem?

 

[Codifus]

...we hear it. When a Word doc is saved, there's probably tons of jitter as the data is transferred from RAM to disk, but so long as the data is bit perfect, which it always is, it doesn't matter, because we don't listen to MS Word;)

 

CD

 

[noogle1]

Any ideas why?

 

[Quest]

actually why doesn't anyone talk about doing both in series?

stuff like the m2tech evo allows async usb and a toslink output.

 

[Miska]

actually why doesn't anyone talk about doing both in series?

stuff like the m2tech evo allows async usb and a toslink output.

 

That's also what any PCI, PCI-Express or ExpressCard with toslink output does. These are by nature all asynchronous. With the difference that cards can read data from computer RAM unlike USB devices which still require driver software to keep on sending data packets to the device.

 

 

[audioengr]

"And FPGAs don't generate jitter unless there's bad design. Gate propagation delays are well understood."

 

Sure they are, however take note as to how many power and ground pins are on a typical FPGA. Not nearly enough to prevent lots of package/internal crosstalk and ground-bounce. When I use them, its for non-jitter-critical applications and I usually reclock afterwards with discrete logic. Here I am divulging all of my trade secrets......

 

Steve N.

Empirical Audio

 

[audioengr]

"actually why doesn't anyone talk about doing both in series?"

 

Not sure what you are asking here. If it is simultaneous S/PDIF and AES/EBU and I2S outputs, several products already do that.

 

If you are asking why we dont send clocks separately with the data, I2S already does that.

 

Steve N.

Empirical Audio

 

[audioengr]

"Maybe I'm thick (!), but I still don't understand why jitter on the data input into a DAC matters if you're not generating the DAC clock from the data. In computing terms audio data rates are really slow, so if you're clocking the correct sequence of 0s and 1s into the DAC, what's the problem?"

 

If you input S/PDIF to a DAC, the clock is generated from that. If there is jitter in the datastream, there will be jitter in the recovered clock. I2S is what is presented to the D/A chip. This is 2 clocks(MCLK and SCLK), word-clock, (which is really a control bit, not a clock), and the serial data. These 4 signals are all generated by the "receiver" chip from the S/PDIF or AES/EBU input. If you input I2S to a DAC, then the receiver chip is bypassed.

 

If there is jitter in the recovered clocks, particularly the bit clock, then the output of the D/A will have Freq. modulation in it. Distortion in other words.

 

Steve N.

Empirical Audio

 

[Miska]

however take note as to how many power and ground pins are on a typical FPGA. Not nearly enough to prevent lots of package/internal crosstalk and ground-bounce.

 

Rough estimate of typical is around 10% of the pins. But good cell allocation map is essential (what goes where, on-chip).

 

Note that also all modern DAC chips employ similar things on-chip. And of course if one doesn't like FPGA it is also possible to manufacture pure ASIC out of the design.

 

Oh, and what wasn't mentioned is that PCB layout and materials are much more important! And also precise internal implementation of particular discrete logic.

 

I usually reclock afterwards with discrete logic

 

I have some discrete logics for other reasons, but otherwise it is possible to achieve very good accuracy.

 

 

[wappinghigh]

I have had a big problem with this in the past and have solved the problem using toslink, via cheap USB converters and separate digital players with toslink out.

 

I'm after an ultra low jitter asynchronous USB-> toslink interface. That does all frequencies on the fly....up to 24/192. Plug and play with Pure Music. Am I asking too much?.

 

[audioengr]

"I'm after an ultra low jitter asynchronous USB-> toslink interface. That does all frequencies on the fly....up to 24/192. Plug and play with Pure Music. Am I asking too much?. :)"

 

No, but I will not be adding Toslink to my products. Toslink compromises the sound too much, so I leave it off.

 

Plug and play is also not a panacea. Turns-out that there are some bugs with async USB drivers from Microsoft. I have not experienced these with a custom driver.

 

Steve N.

Empirical Audio

 

[Quest]

"I'm after an ultra low jitter asynchronous USB-> toslink interface. That does all frequencies on the fly....up to 24/192. Plug and play with Pure Music. Am I asking too much?. :)"

 

don't know if m2tech evo can fit your bill.. as far as i know, it is async, has toslink and 24/192.

 

[noogle1]

@Steve N -

I was talking about DACs that don't generate the clock from the S/PDIF data. I'm still not sure why a bit of jitter on the input data matters here, since the jitter is miniscule in comparison to the width of the data square-wave.

 

[audioengr]

"I was talking about DACs that don't generate the clock from the S/PDIF data. I'm still not sure why a bit of jitter on the input data matters here, since the jitter is miniscule in comparison to the width of the data square-wave."

 

All DAC's need the I2S clocks. These are generally generated from the incoming datastream.

 

In the case of your Naim DAC, it generates the clocks from local oscillators, so the incoming jitter in unimportant. The only jitter that is important is that of the internal oscillators and associated circuitry.

 

The jitter is very tiny in comparson to the period of the square-wave, but still matters.

 

The reason for this is: the D/A conversion needs two things:

 

1) accurate data

2) accurate timing

 

Accurate timing means that each time a new word is applied to the D/A chip, it must occur at a precise point in time, not earlier or later. If it is captured by the D/A chip earlier or later than the ideal time, then it creates a time compression or expansion of the music waveform. This is frequency modulation. It turns-out that the magnitude of this modulation can be very tiny and it can still be audible. This happens because the modulation frequency is not only in the audio band, but it can track the music waveform. This is what is called "correlated jitter". This makes it very easy for the human ear to hear the effects, even at low amplitudes.

 

More on jitter:

 

http://www.positive-feedback.com/Issue43/jitter.htm

 

http://www.positive-feedback.com/Issue22/nugent.htm

 

http://www.positive-feedback.com/Issue14/spdif.htm

 

Steve N.

Empirical Audio

 

 

 

[Talk2Me]

Sorry to brig this back from the dead, but I find this thread very valuable concerning the whole usb vs toslink debate, and it just died.Then there is firewire to confuse me even more (if that is even possible )

 

[Quaternione]

Very interesting reading, indeed.

Now in this Jitter discussion, what about streaming music over the network, e.g. via Apple TV2 (which actuall I am currently testing with). I don't know how the ATV works internally, but assume it has a build in buffer that would store the data sent via the network before sending it to the DAC. Shouldn't that allow for less Jitter compared to USB or SPDIF?

Thanks

Volkmar