|
Home
/ FAQ
/ News Classifieds / Events |
Audio Asylum Thread Printer |
Get a view of an entire thread on one page |
208.100.141.234
In Reply to: RE: Jitter Research, Analysis & Measurement posted by cics on March 25, 2008 at 22:48:01
"Remaining clock signals entering the chip will carry jitter which is not directly related to the master clock jitter. Of course if these are are grossly jittered other issues arise. My understanding is that for these non critical clocks, level detection is used (as opposed to phase)."
There is only one synchronous clock used on a DAC chip. The others are not effectively clocks. Sometimes the MCLK is used to do digital filtering, but does not affect conversion, which is where the jitter becomes audible.
"Both the clock and data inputs however carry noise. This noise infiltrates the chip. Noise as mentioned before includes EMI (as in induced currents), RF pickup (into GHz), IMD, signal reflections and thermal noise. Remaining clock signals have jitter which I see as phase noise and this adds to the overall noise contamination."
No, only the single clock signal matters. Once the data is clocked into the first flip-flop in the D/A converter, only the clock matters.
"If chips are free from such contamination entering it, then yes only the master clock signal needs treatment. This is a large assumption."
The data can be jittering a lot, but it does not matter. Only the clock matters. This is fundamental synchronous logic. Contamination means nothing. There is no such electrical phenomenon as "contamination", except maybe in water sources or air etc.. It is either timing jitter, ground-bounce or crosstalk.
Steve N.
If there's ripple voltage riding on the data input single (for example), are you saying this will NOT impact jitter? If so, how?
No, only the single clock signal matters. Once the data is clocked into the first flip-flop in the D/A converter, only the clock matters.
Data sent to chip is at bit level where the bit clock matters. How else would the chip determine actual signal amplitudes (16 or 24bit)?
Any time data is moved from one point to another in an audio digital component, that data can modulate the clock because of real impedances in the circuit traces, and in the D/A convertor chip itself. This is especially problematic at very low audio signal levels in a PCM-based system because the two's complement data words go from all zeros to all ones at or near the zero crossing point, and so the music signal, which is repetitive by nature, can easily couple to the clock as data correlated jitter.
As an example, consider a digital filter outputting a 1Khz low level sine wave encoded data signal, along with the bit clock and word clock to the D/A convertor IC. Each of these signals must 'travel' from the digital filter IC to the DAC IC and back. All share the same reference at the DAC IC, but the average level of the data line will alternate between a high and low state, causing the power and the ground to change during the time as well because of the impedance of the power and return paths. This changes the clock threshold level in the DAC IC (as well as modulating the clock amplitude at that same 1KHz rate) resulting in data correlated jitter. Even if the jitter was zero at the output of the digital filter, it is present at the DAC (and easily measurable I might add).
This is the same type of situation you have with asynchronous clocks running a FIFO or any other buffer device. The input clock modulates the time and frequency parameters of the output clock (and vice versa) because they are connected to the same device and hence share the same power and ground system. In addition, the data will modulate the clocks as previously detailed. Every edge transition or level change in the system creates a background of noise on the power and ground lines that will ultimately modulate the clock at the DAC IC. In order to effectively remove the jitter and not reintroduce it requires isolation techniques that are not commonly used and are somewhat expensive to implement.
Very interesting and makes a lot of sense.
With lower levels we get no information in the higher order bits thus alternating signs cause signal changes from largely all 0's to 1's as you mention. This data related noise probably gets worse with increasing frequency as there's more frequent swings between signs (with same amount of unused higher order 0's and 1's).
Many implementations do suffer from ground-bounce and crosstalk, so I agree this can be a problem. I have found that designs in the field of consumer electronics are frought with these problems, even from large multinational companies. Many of the mods that I have done in the past repair these types of problems.
I implement many of the isolation techniques you mention in my own products, so I dont have this problem. My circuits behave closer to the ideal. Separate power feeds, isolated return traces, effective decoupling and termination/impedance matching etc..
This is simply ground-bounce and crosstalk between traces and with power supply. With proper circuit design and board layout, these can effectively be minimized so that they are inaudible.
But I haven't heard your stuff so can't comment on that.
I think we've talked about this before, but separate return paths don't really effectively address the problem since the signals generally all share the same source and return pins. Better to have a close layout with an extremely low impedance return path (typically an uninterrupted ground plane directly above the signal traces) except this isn't always possible if you want the digital filter and all of the other high jitter signals isolated from your clean clock and D/A convertor.
One method that works pretty well for me is generating the clocks in an isolated section (using BB ISO 150 device) along with the D/A convertor and analog stage, and then clocking the data across the barrier. Not perfect, and everybody has their own way, but you have to break the jitter path at some point.
"If there's ripple voltage riding on the data input single (for example), are you saying this will NOT impact jitter? If so, how?"
If the setup and hold times are not violated, then the data will be clocked into the first flip-flop inside the D/A chips without error. If it meets these criteria, then only the clock that clocks the data has any effect on the timing. This is fundamental synchronous logic 101.
"Data sent to chip is at bit level where the bit clock matters. How else would the chip determine actual signal amplitudes (16 or 24bit)?"
Data sent to the chip is either ones or zeroes. It is the output of the D/A where the voltage varies. The contents of each data frame on the input determines the word size. The frequency of the input stream to the D/A chip determines the sample-rate.
There is a lot of misinformation and misunderstanding of these processes. Listen to the engineers that have the education in these areas.
Steve N.
What you explaining is how the chip accurately decodes binary signals, so setup and hold times are important in this regard.
On data input, looking at the AKM DAC example, the following is explained in its operation:
In all modes the serial data is MSB-first, 2's compliment format and is latched on the rising edge of BICK.
It goes on to explain that BICK must present and so on...
What you avoiding is the lack of noise immunity thats riding these signals. A Flip Flop is a switching circuit that still maintains current flow. Noise coupling remains a factor.
cics and all of his groupies should read:
http://boards.psaudio.com/showthread.php?t=3412
http://www.psaudio.com/newsletters/3-08.asp
Bottom line, a Toslink digital output from a stock soundcard isn't going to produce SOA results no matter how much plug and play PC tweaking cics does.
PS- cics have you ever built or modifed/upgraded any DAC?
Noise coupling is not a factor. The data has almost a full half cycle of setup and hold time with respect to the clock rising edge. There are no violations, therefore noise on the data signal is not a factor. Only the noise on the bitclock (SCLK) is a factor.
The kind of noise you are talking about is well below the switching threshold in 99% of designs. If this is not the case, then the design is severely broken and should be redesigned anyway.
Steve N.