S/PDIF Jitter: Myth or Reality?

Status
Not open for further replies.
Jump to Latest
U

Ulas

Member
Joined 2003
#1
Many here are willing to accept the guaranteed jitter created by asynchronous reclocking rather than suffer the horror of S/PDIF jitter. That’s their choice; but it is a choice based on myth, superstition, and ignorance.

Here are some spectral plots of two different DACs. Both are feed by the same PC-generated S/PDIF signal. If S/PDIF jitter were so pervasive one would expect to see its manifestations in all DACs connected to it but that’s clearly not the case. In the plots below, J-Test refers to Julian Dunn’s jitter test signal, which is supposed to be especially sensitive to data-correlated jitter, the kind of jitter S/PDIF is supposed to have. All test tones were created with DACtester v0.8d.

DAC “A” is everyone’s favorite, eight TDA1543s in parallel. This DAC is described as sounding most “analog-like.” I guess to someone whose only exposure to analog music reproduction is a thrift store turntable and a “little rat” phono stage. Why are DACs always compared to some unspecified “analog-like” sound? What’s wrong with using live acoustic music as a reference? I know, you have to dumb-down the reference otherwise digital audio will never measure-up.

DAC “B” is a mystery DAC.

First, here is DAC “A” with its “analog-like” sound dealing with J-Test. Oh, the horror. Look at those nasty sidebands created by the S/PDIF-induced data jitter.

Here is DAC “B” with the very same J-Test signal played through the very same S/PDIF connection: Only the DAC was changed. Why, how can that be? I thought S/PDIF was so horrible that anything would be preferable.

Second, here is DAC “A” trying to produce a clean 11KHz sine wave. Tell me, if a DAC can’t reproduce a clean, single-frequency sine wave how can it accurately reproduce more complex music?

Here is DAC “B” with the very same sine wave played through the very same S/PDIF connection: Again, only the DAC was changed.

Third, here is DAC “A” with a 1KHz sine wave.

Here is DAC “B” with the very same sine wave played through the very same S/PDIF connection: Again, only the DAC was changed.

Do you notice a pattern? The problem is not S/PDIF, but the implementation of particular S/PDIF receivers.

Note: No snake oil or audio voodoo was used in this comparison.
 
#3
OK, I can see a difference in the traces. But what am I looking at? What is the vertical and horizontal scaling?

S/PDIF distorts the eye pattern when carried over a real piece of cable because of its violation of Manchester coding to mark the beginning of a word. If you recover your clock just before that violation occurs, you have a much better chance of rejecting jitter. You appear to be demonstrating a better clock recovery scheme. Yes?

As for 1543 being everyone's favourite, count me out. It's flawed.
 
#7
Ulas said:
The problem is not S/PDIF, but the implementation of particular S/PDIF receivers.
Click to expand...


very old news, Mr Ulas, there is a decent implementation published on my website:

http://www.tentlabs.com/Products/DIYDAC/DIYDAC.html

and specifically

http://members.chello.nl/~m.heijligers/DAChtml/dig_r2a.pdf (input receiver)

http://members.chello.nl/~m.heijligers/DAChtml/dig_r2c.pdf (secondary PLL)

Once the receiver side is optimised, the transmitter can be improved (low jitter clock, SPDIF reclocking and decent buffering with Zout=75 ohm), and these improvements can still be heard (and measured).

Given the amount of effort one has to put into optimising an SPDIF chain, I'd be more happy with another interface, maybe a bit more expensive but much less hassle compared to getting things right using SPDIF.
 
#8
I guess that non-oversampling TDA1543 DAC circuit was tested, with almost no output filtering. No wonder that spectral analysis of analog output is full of noise. Every "standard" oversampling DAC with digital and analog filter will perform better in this test than the non-oversampling non-filtered one.
 
#9
Re: Re: S/PDIF Jitter: Myth or Reality?

Guido Tent said:
Once the receiver side is optimised, the transmitter can be improved (low jitter clock, SPDIF reclocking and decent buffering with Zout=75 ohm), and these improvements can still be heard (and measured).

Given the amount of effort one has to put into optimising an SPDIF chain, I'd be more happy with another interface, maybe a bit more expensive but much less hassle compared to getting things right using SPDIF.
Click to expand...
I really appreciate the work you've done on said DAC, however it hasn't solved the problem completely. PLL cannot achieve complete independence on the input signal and hence different approach shall be used and I bet you will no longer be able to tell any difference.. it's on the complex side, but it's achievable.. I'd be also happy to have different interface, but unless it's bidirectional and electrically isolated it wouldn't solve the jitter problem completely either.. the world gave us S/PDIF and we have to deal with it as best as we can..
 
#10
Re: Re: Re: S/PDIF Jitter: Myth or Reality?

Glassman said:

I really appreciate the work you've done on said DAC, however it hasn't solved the problem completely. PLL cannot achieve complete independence on the input signal and hence different approach shall be used and I bet you will no longer be able to tell any difference.. it's on the complex side, but it's achievable.. I'd be also happy to have different interface, but unless it's bidirectional and electrically isolated it wouldn't solve the jitter problem completely either.. the world gave us S/PDIF and we have to deal with it as best as we can..
Click to expand...

well, that is more or less what I wrote......

The PLL driving a VCXO in the CD transport, and a fixed oscillator in the DAC, is a next step to expand SPDIF (the control voltage for the VCXO is the extra wire) but still the transport quality (in terms of jitter) counts.

After all I prefer a one box solution

best
 
#11
I'm thinking in the realm of ordinary one way S/PDIF connection with no modification required on the transmitter side and no PLL used whatsoever.. VCXO near the DAC, but controlled in a particular way which guarantees true DC on the oscillator input..
 
#12
Glassman said:
I'm thinking in the realm of ordinary one way S/PDIF connection with no modification required on the transmitter side and no PLL used whatsoever.. VCXO near the DAC, but controlled in a particular way which guarantees true DC on the oscillator input..
Click to expand...

true DC is impossible, near DC is the goal

that is what the analogue loop does in the DAC linked in this thread. The bandwidth is about 1 Hz. Using a digitally controlled loop can bring that down further, see for example:

http://www.grimmaudio.com/cc1grimm.htm

best
 
#13
you're right, nothing is perfect, only something that last unchanged since the Big Bang would qualify.. the analog loop in your DAC passes everything upto 1Hz and starts attenuating progressively frequencies past 1Hz.. what I'm thinking of is say sub-0.1Hz with absolute immunity to input variations of any higher frequency.. and by DC I mean DC with about 100dB SNR with adjustments less frequent than once in 10 seconds..

nice figures for CC1, I appreciate Grimm stuff..
 
#17
Re: Re: Re: Re: S/PDIF Jitter: Myth or Reality?

Guido Tent said:
PLL driving a VCXO in the CD transport, and a fixed oscillator in the DAC, is a next step to expand SPDIF (the control voltage for the VCXO is the extra wire) but still the transport quality (in terms of jitter) counts.
Click to expand...

Mr. Tent,

Could you explain why the transport jitter still counts, when using the quoted approach?

Regards,
Alexandre
 
#18
Hi Alexandre,
The fewer errors that exist, the better off you are. Many errors can be corrected by the C1 and C2 error correction stages, on a good disc with a fresh transport. You may still get some that get tagged as unreliable data and sent out depending on the electronics.

Now, a less expensive transport may have an eye pattern that has a lot of jitter, and high noise. This is an RF analog signal comming off the disc. So the more noise and timing errors there are here, the more errors escape to the Dgital to Analog section. The D/A section can not perform well when you feed it poor data. In this regard, the Philips VAM1202 is terrible. The worst I've seen from a new transport, and variable at that. Non-repairable, of course. Same for the decoder board.

Now you can see that you have to start with a good transport in order to get good, valid data out.

-Chris
 
Status
Not open for further replies.
Top Bottom