Frequently Asked Questions

This product is discontinued. This is an archived page.
  1. Asynchronous Reclocking
  2. I2S
  3. Output Stage
  4. Error Correction vs. Jitter
  5. Slaving Computer Soundcards
  6. Battery for Digital Schematics?
  7. Stacking Multiple Converter Chips
  8. Benchmark's UltraLock
  9. Digital Filtering
  10. One-box CD Players
  11. Synchronous Reclocking
  12. Jitter Sources
  13. Large Buffer
  14. Disbelief in LessLoss
  15. A/D Converters
  16. Sampling Rates

Question:

In your FAQ, or the PDF, I noted no discussion on how your slaved-CD/clock approach *differs* from ubiquitous I2S designs many DIYers are using. Can you elaborate?

LessLoss Reply:

Very often this comes up in marketing language in all the wrong places. What I2S is is a digital protocol (a digital signal) which is divided into three separate signals: clock, bit signal and sample clock (which denotes left or right sample). This is different from S/PDIF digital, which has the clock signal integrated into the data stream. Basically, I2S is another way of getting digital information from point A to point B. You may want to know that we use it in our design as well: from the S/PDIF input receiver to the oversampling chip. Yet another internal digital protocol is used from the oversampling chip to the DAC chip. I2S can indeed be used between a CD Player and DAC, and, if the DAC is connected in the standard way (when the DAC is slave to the CD Player), then I2S will outperform S/PDIF with regards to Jitter because it carries the clock along that third separate piece of wire. BUT, the prerequisite for this to hold true is that the digital cabling used is at least of the same high calibre. It is not true that using any three cables for I2S unbalanced signal transfer will automatically result in less Jitter at the DAC chip itself. Indeed, it can actually easily be argued that the Jitter induced in Clock extraction from SPDIF can actually be less than the Jitter induced by using three clock cables (which are all antennae). You raise the RF induction by three times the amount when using three cables in comparison to using only one well shielded one.

However, our solution by far tops even that solution, because what we do is we actually digitally slave the CD Player to the DAC, which is the only way to truly ensure that the Jitter which always comes from the CD Player's digital signal is quantized into place via completely synchronous reclocking to the original master clock just before the actual conversion process. I2S alone without reclocking cannot do this. Think of it as S/PDIF with three wires instead of only one. And please see 'The Digital Forest' for an explanation of how Slaving works and differs from other existing solutions. (You've probably already studied that page).

Here is some typical marketing language that many DAC manufacturers use:

> On I2S connection the digital signal is directly transferred to the DAC without jitter;

And our reaction:

Hmmm. Extremely interesting. The Master CD Player transfers the "digital signal directly to the DAC without jitter". Wow. Did you read that? They are saying that they have no jitter at the DAC! Would you believe that. Guess it is time for us to go bust, in that case... :-) Seriously, now, it's hogwash. When we say that every millimeter counts, we really mean it. Anyone who is serious in HF design knows this, even if they don't design high performance gear. In a master DAC solution, the synchronous reclocking gives you extremely high performance, and the clock is located just a few millimeters from the DAC chips themselves. Other features we offer such as galvanically separating the ground from the digital schematics to the analogue schematics and then feeding the analogue schematics from two balanced batteries offers a level of quality which dwarfs a simply slaved device with I2S.

Some people believe that they get a better sound through tubes. What they believe is that they are lowering Jitter. We don't. We believe that using no tubes and no transformer and using pristine balanced battery power is the best. For us, tubes color the sound and we have never heard a tube system which didn't sound like tubes (rounded sound due to harmonic structure of the distortion). Some people like this type of sound, but we don't. We feel it makes all recordings sound somewhat similar. This can be used to make the recording according to taste, but we prefer not to color the sound in our DAC. We prefer the lowest possible distortion using the best possible power supply and lowest Jitter. However, some people use tubes in their preamp and they are very happy with the result.

It is **harder** to get rid of all Jitter than to put on some tubes and smear the digital grain out of the signal. It is true that digital sounds harsh when there is jitter. It is extremeley difficult to get rid of all jitter. We are trying to work in this direction (see our digital cable development, and our unique power filtering solution).

i2s is a different format containing the same information as S/PDIF. It can be argued that by not converting to S/PDIF in the first place, that the Jitter amount of the data stream is kept low because no conversion of the format needs to take place in real time. Not all real-time process which are done to a digital stream must necessarily raise the Jitter amount. In our solution, we use synchronous re-clocking. We use this multiple times at crucial stages in the data stream from the laser pickup mechanism all the way to the very DAC chip, which is galvanically isolated from the rest of the digital ground of the converter (this is almost never done and differs completely from what is normally pictured to be two deparate PCB's with a bus connecting them, raised into the air and which actually does much more harm in terms of Jitter than good!) The conversion to SPDIF need not necessarily be jittery since the only real place that the Jitter amount is important, really important, is at the actual D/A process, since this is where the distortion of the audio signal is born. Otherwise there can be Jitter in great amounts and there is still no data loss at all. Just small timing errors. But if these are successfully dealt with before conversion, you'll never hear them. And it doesn't matter where and when they are dealt with. What's important is at the DAC chips. That is the holy altar, so to speak, the moment of truth.

The use of i2s is most audible if you use the DAC as slave to a digital source. In that case, since there is no possibility to re-clock the jittery data stream, it is better not to convert the data stream's format in the first place, but it is still very important to keep all sorts of other factors in order: constant impedance over the digital lines (i2s has more signal strands than SPDIF, which needs just one coax cable), high shielding effectiveness, good connectors, etc. So it is not so simple as to justify saying: "i2s is better than SPDIF". You can only say that on a certain system configuration, "i2s may be better than SPDIF", and that this system configuration is the one where there is no re-clocking possibility, and where the I2S digital cables are at least as good as the SPDIF cable.

The largest problem is not the method of transfer of the digital stream (LAN, wireless, S/PDIF, i2S, AES/EBU, TASCAM) but the amount of jitter in the oscillator which gives the sampling rate to your digital stream.

Remember that with a synchronous reclocking solution, most of the timing errors come from HF interference, not from data induced Jitter. If the cable is properly shielded, the other problem to deal with is the characteristic impedance so there would be no reflections.

The real quality lies in the clock stability management throughout the entire holistic solution all the way up to the DAC chips themselves, and the use of I2S can indeed be a useful step in that direction, but it is far from the only possible and necessary step for top-quality performance.