Hi Eric,
the subject is quite large and complex, I could easily write a couple books about it, but I'll try and put it all together in a nutshell here.
To make all the rest make sense you have to have SOME understanding of jitter, its impossible to understand why different implementations may or may not be better without some understanding of what it is. Jitter is the variation in timing of samples applied to a DAC chip, this is what matters. The whole concept of digital audio is that "samples" (numbers that represent the musical signal value at a precise point in time) are applied to a DAC chip at very precise times. (a CD applies these samples at 44100 times per second). If anything causes the time between samples to change even slightly, the waveform at the output of the DAC is distorted. Human hearing seems to be very sensitive to some forms of these timing deviations.
A few things about jitter, number one, it is ALWAYS there, no matter what some marketing departments tell you, it is impossible to produce a zero jitter signal. You can get it pretty small, but its always there. Different circuits produce different amounts and types of jitter. Even the same circuits can produce radically differening amounts of jitter with different amounts of noise on the power and ground lines supplying the circuit.
There is a major tradeoff here, many of the methods used to decrease jitter actually wind up producing significant amounts of ground plane noise, which winds up producing more jitter than you thought you were getting rid of in the first place. This is not understood by a lot of designers today, thier attempts at reducing jitter actually make things worse.
Now on to some specifics. First lets talk about S/PDIF. This is a class of protocols in which the source is "in control". The rate at which the data comes over the wire is completely determined by the source. The DAC has to somehow "lock on" to the data stream and produce a signal going to its DAC chips based on the rate at which data is coming over the wire. This has traditionally been difficult to do with very low jitter. This is traditionally been done with a device called a Phase Locked Loop (PLL). A PLL locks on to the input data stream and produces it own "clock" which tracks the input signal. Unfortunately the jitter from a PLL can have anywhere from 2 - 200 times as much jitter than a good fixed frequency clock (such as a crystal oscillator). How good that PLL does is VERY dependant on the signal feeding it, ie the transport. In the early days many transports were not very good and the PLLs in the DACs did a very poor job of extracting a clock from these signals. This gave rise to the "reclocking boxes". These contained a a much better PLL (and expensive) PLL which did a much better job of extracting a clock from the source and feeding it to the DAC, which now had a better signal to start from. Transports have gotten better and DAC receivers have gotten better, so outboard PLLs are less effective than they used to be.
So this brings up the first thing people realized, trying to track something else will almost always have more jitter than if the DAC generates its own clock. Thus was born various methods to have the source follow the DAC. Some companies put the clock in the DAC and fed it to the transport. This should completely fix the problem, but it didn't. Other "computer" protocols were tried such as asynchronous USB and ethernet protocols. Both these allow the low jitter clock to be in the DAC, and the source follows the DAC. But non of these have been completely successful, in that ALL of them still are susceptible to what is going on in the source. The problem is that most of the designers are ignoring the fact that that these "feed forward" systems generate more noise in the DAC power supply and ground plane, which increases the jitter of the local clock.
I'm a very big fan of the Squeezebox system, what drew me to it in the first place was the architecture, a local low jitter clock that fed the DACs and a system which grabbed data from a server when needed rather than a server which shoved data out when it wanted to. Unfortunately the ethernet system requires a local computer (ALL ethernet streamers have a computer built in) , and complex software, which generates a ton of noise on the PS and ground planes which compromises the theoretical extremely good jitter performance. Unfortunately none of the companies making ethernet streamers have realized this and designed their systems with this in mind. I personally think ethernet streamers are a very good way to go, but there is a lot of work to fully realize the potential.
Asynch USB should be a good compromise, the protocol is much simpler than ethernet protocols, so properly using them should generate much less noise, and it still offers a way for source to be slaved to the DAC. But it STILL does generate some noise from implementing the protocol which will generate noise on the ground plane. Designers have been almost ignoring this aspect. A few have made some attempts at mitigating this, but NOBODY as really come close to addressing this fully.
So why have I chosen the path I'm taking with this DAC? Its a good compromise. S/PDIF is very common, almost every device that deals with digital audio supports S/PDIF, async USB and ethernet audio are a much smaller space, I wanted to produce a DAC that would be useful to a very broad range of people and circumstances. The only problem was coming up with a way to implement it that would be as good as other methods. I think I have achieved that.
So for people that don't have an S/PDIF output but do have a USB jack, I added a USB input which should be quite good. If you want to go ethernet streaming you can get a squeezebox Touch and plug it into this DAC, no need for a very expensive ethernet streamer made by an audiophile company.
I hope that sheds a little light onto this rather large mess that is digital audio.
John S.
