JJZolx wrote: > How does jitter get through an asynchronous interface? Isn't that a bit > like talking about jitter on an Ethernet connection?
Good question, unfortunately things are not as simple as it seems on the surface. The supposition goes that as long as you have a local clock, the only jitter you can have is what is inherant to the clock itself, but there is more to it. It's primarily noise on the groundplane. Let's first look at how "digital logic" works. You have transistor circuits running in a high gain mode with a "threshold" which is some ratio between the VDD and VSS power nets (power and ground). The signals going between chips are not perfect, they take a finite amount of time to transition between a high and low (and low to high) state, the voltage "ramps" between the states. Exactly when those transistors "switch" is dependant on when that ramp reaches the threshold of the receiver, and that threshold is dependant on the instantaneous voltages on VDD and VSS. Thus any noise on either power or ground will cause the time at which the threshold is reached to vary, otherwise known as jitter. This noise on the supply nets comes from current flowing through the "wires" in three places, the chip itself, the package the chip is in, and the board the chip is soldered to. The first two are just influenced by what is happening in the receiving chip itself. Note that this includes all the input signals. Every time an input changes state current flows through circuitry in the chip causing noise which will add to jitter of other input signals and outputs. How much noise happens internally is extremely chip dependant. A very robust power network in the chip will generate very little noise, but a very robust power network increases chip size and cost, there is always a tradeoff here by the chip makers. Certain chip functions (such as recloking flops) can actually change the sound depending on which manufacturer and logic family is used, simply because of variations in internal power networks. Noise developed across package wires is similar to chip noise, though much simpler since it is JUST dealing with the I/O signals. Here smaller packages are usually better. The groundplane is where all the fun comes in, because here we can have chips whose signals are not connected affecting another chip, and processing going on in a chip affecting another chip. Groundplanes are NOT equipotential everywhere, currents flowing through the plane DO generate voltages across the plane. They are not huge, but they ARE there. Unless you are very careful about parts placement and groundplane design it's very easy to have circuitry on the board causing noise which can significantly increase the jitter of that "ultra low jitter" clock you are relying on to provide a very low jitter clock to your DAC chip. I hope it's obvious by now that this groundplane noise is not static, it ebbs and flows with the switching going on in the chips, which can change due to jitter on the inputs of THOSE chips. Not just jitter but things like packet timing (both USB AND ethernet) can have a big impact on the dynamic nature of this groundplane noise. This is why my prefered method is to have the USB receiver chip powered by VBUS with an isolator on the OUTPUT signals going to the DAC chips. This way the ground planes are completely separate and the noise caused by all the processing going on in the USB receiver chip cannot get get into the sensitive DAC groundplane. Jitter on the signals can still cause groundplane noise, but that is much less than the noise from the processing in the receiver chip. Ethernet has exactly the same issue (if not worse), ideally you would have a separate ethernet processor with an isolated groundplane so all the stuff going on in there is not producing noise getting coupled into the groundplane around the clock and DAC chips. For something like the Touch with an integrated processor there should be separate groundplane for all the digital stuff and the "audio" stuff (clocks, reclocking flops, clock muxes, DAC chip, S/PDIF output). So yes even an asynchronous interface with a local clock can be affected by jitter and other timing issues on the input interface. The causes and fixes are much more subtle and difficult to analyze than the "first order" effects such as PLL jitter. Getting rid of them in a design are much more implementation detgails such as exactly how the groundplanes are implemented and exactly where the chip are places and signals routed rather tghan broad catagories such "asynchronous" or PLL or ASRC. These are real and do affect sound but it's really hard to talk about in marketing literature! John S. ------------------------------------------------------------------------ JohnSwenson's Profile: http://forums.slimdevices.com/member.php?userid=5974 View this thread: http://forums.slimdevices.com/showthread.php?t=94822 _______________________________________________ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/audiophiles
