Understanding the Dunn & Hawksford paper on SPDIF

[percy]

Ok I have read that paper but I need help clear up a few things for me.

From what I understand, all arguments in that paper held against spdif hinge on the assumption that the connection is severly band-limited. Which boils down to low bandwidth/quality cable and mismatched terminations (i.e not 75ohm on either end). And once that happens, the amount of jitter depends on the data value, or more precisely the amplitude of the original signal. Lower amplitudes yield higher jitter.

What I am having a tough time understanding is that if the connection is NOT band-limited and is perfectly matched then is it still a problem ? Shouldn't it be just fine to use spdif then ? Is it really difficult to implement a not-so-band-limited spdif connection ?
Or what am I missing here ?

 

[jwb]

You're right that a higher bandwidth cable will improve S/PDIF jitter performance. It's stated right there in the Hawksford paper. But you still have the data dependence, because you get a different number of transitions on 1 bits compared to 0 bits. There's no way to solve this problem.

These days we have a far better means of transmitting digital audio: I2S protocol using LVDS on shielded twister pair cable. Simple, cheap, and effective.

Still, nearly every amateur will be implementing at least one S/PDIF receiver for compatibility reasons.

 

[hagtech]

Bandwidth works two ways. Keep in mind you also need very good low frequency performance with S/PDIF. The better you do the bottom end, the less jitter you get from the HF edges.

jh

 

[percy]

But you still have the data dependence, because you get a different number of transitions on 1 bits compared to 0 bits. There's no way to solve this problem.

and since the instantaneous sample rate is continously being "derived" from the bit stream it will cause the PLL on the receiver side to adjust every so often and thus cause jitter ? did I get that right ?

if the above statement is correct then if there was some way of eilminating the pll (fixed clock(s) with "manual" sample rate selection) then even this wouldn't be an issue, right ?

Bandwidth works two ways. Keep in mind you also need very good low frequency performance with S/PDIF. The better you do the bottom end, the less jitter you get from the HF edges.

jh

hmm...didn't quite follow that..could you please elaborate ? thanks.

 

[jwb]

and since the instantaneous sample rate is continously being "derived" from the bit stream it will cause the PLL on the receiver side to adjust every so often and thus cause jitter ? did I get that right ?

Sure, if the recovered S/PDIF clock is discarded then the jitter on it is irrelevant. The canonical means of achieving this is to export the DAC's clock to the transport.

 

[percy]

ok got it!

although with that approach and, also with I2S, it would mean sending a very vulnerable XX Mhz square wave signal over a wire. Wouldn't that be an open invitation to RFI/EMI ? Guess what I am saying is that it might fix one problem but create another, and still not be the silver bullet we are seeking ?

Seems like discarding or not even recovering the clock at all and implementing a "buffered" DAC with its own independent clock would be a perfect solution, atleast theoritically.

 

[dswiston]

As mentioned earlier, if you used LVDS (and good wire) to transport the signal I'd reckon that would almost be a non-factor. LVDS is used in hundred of megabit connections (100s of MHz+) on backplanes etc. A couple of MHz of I2C should be no big deal.

Proper termination would still be important (LVDS looks for 100ohm differential) and you couldn't expect to have 100s of feet of cable either. I'd imagine the inductance would go through the roof and square waves don't like inductance.

 

[jwb]

Proper termination would still be important (LVDS looks for 100ohm differential) and you couldn't expect to have 100s of feet of cable either. I'd imagine the inductance would go through the roof and square waves don't like inductance.

LVDS doesn't use square waves, it uses slew-rate-controlled shaped edges and minimum transitions. And you could certainly expect to have hundreds of feet of wire at these speeds. 300 feet at least.

 

[percy]

I2S with LVDS does look promising.

jwb, I found a really old thread started by you, in which you discussed about using LVDS. There weren't any updates later though. What was your experience with that ? How did it go ?
I'd interested in checking out work done in this area.

 

[dswiston]

LVDS doesn't use square waves, it uses slew-rate-controlled shaped edges and minimum transitions. And you could certainly expect to have hundreds of feet of wire at these speeds. 300 feet at least.

Theoretically, nothing is a square wave outside of an idealistic world. I think it is a safe enough assumption that sub nanosecond rise/fall times with few MHz cycle time signal can be lumped as "square".

 

[jwb]

Sub-nanosecond rise times sound scary if you are thinking about 5V CMOS signals. But at 250mVp-p, those speeds do not cause big EMI headaches.

A 192kHz 64-bit data transmission for digital audio requires less than 13Mb/s. At this rate the LVDS standard allows rise times as leisurely as 25ns. You can use very, very long cables at this data rate. Obviously shorter is better: longer cables are likely to create more jitter.

Answering the other question, a lot has changed since I wrote that original post. The 3M MDR cable system is now obsolete and extremely expensive. I now use plain old shielded ethernet cables instead. You could probably also use DVI cables and connectors, if those are cheaper or easier to obtain. There's enough pairs in an ethernet cable to get the job done for I2S transmission.

National still makes nice quad LVDS transmitters and receivers, but Texas Instruments also has a complete line these days. My next DAC, not yet built, will use LVDS for internal and external clock distribution. Analog Devices now makes clock fanout chips with < 1ps additive jitter.

 

[hagtech]

slew-rate-controlled shaped edges

Makes me wonder, if there is an active circuit controlling slew-rate, I wonder if it could add jitter or timing errors. After all, this is yet another (probably feedback) circuit component to impart a signature on the waveform.

Or perhaps, by removing the excessive HF information and noise (think Shannon here) it ends up improving signalling. I do a similar thing with passive circuits in one of my DACs.

Obviously shorter is better: longer cables are likely to create more jitter

Um, this is not necessarily true. Upon what do you base your conclusion?

True. longer cables have dispersion, but that's not really an issue with reasonable length (<10 meter) lines. And you can always do equalization (been done for 100 years now).

In fact, shorter cables can have the worst problem, especially if they are on the order of transition time. That is, if you are running 5ns edges, a 1 foot cable is likely the worst. Any termination reflections get bounced back and forth between receiver and transmitter causing irregularities in the risetime waveform. A 1 foot cable is a little under 2ns in length. This effect works on multiples of the fundamental wavelength (spdif bit rate). Best to keep the length of your cable such that re-reflections do not occur at transition.

So cable is super short (inches), or 1m. Anything in the middle might have consequences. Of course, susceptibility is fully dependent on the quality of the terminations and cable. A very good wideband termination will not have these issues.

jh

 

[jwb]

Makes me wonder, if there is an active circuit controlling slew-rate, I wonder if it could add jitter or timing errors. After all, this is yet another (probably feedback) circuit component to impart a signature on the waveform... you can always do equalization ...

First you said a negative thing about feedback, then you said a positive thing about pre-equalization. Contradictory, don't you think?

With a point-to-point LVDS connection properly terminated, you won't have reflection problems at any cable length.

 

[FastEddy]

" ... A 192kHz 64-bit data transmission for digital audio requires less than 13Mb/s. ..."

This might be pushing packet switching technology a little, practically speaking ...

Duplex USB 1.1, for example, can pass around 1.2 Mbytes/s, but with hubs in the circuit, the real, available band pass may degrade to half that.

USB 2.0 in simplex mode, proports to pass close to >30 Mbytes / sec., but w/hubs, really its about half that.

FireWire 400 can do close to 40 MegaBytes / second, in duplex and w/hubs around 75% of that ('cause its all peer to peer). (FW 800 = 2 times bandwidth 'cause of double duplex.)

All above are 32 bit processed, but that is not necessarily a disadvantage when pushing around 24 bit audio data.

(Sorry to be buttinsky ... )

 

[chris719]

Don't forget Ethernet... cheap, fast and ubiquitous.

 

[jwb]

" ... A 192kHz 64-bit data transmission for digital audio requires less than 13Mb/s. ..."

This might be pushing packet switching technology a little, practically speaking ...

Duplex USB 1.1, for example, can pass around 1.2 Mbytes/s, but with hubs in the circuit, the real, available band pass may degrade to half that.

I said bits, you said bytes.

 

[FastEddy]

" ... Don't forget Ethernet... cheap, fast and ubiquitous. ..."

Yes, yes and yes.

FW 400 is about 15% faster than 1000baseT EtherNet ... and in bulk filre transfer mode, can stream four DV quality videos to EtherNet's single DV quality video stream.

Fiber-Channel (or Fibre-Channel if you prefer) can match FireWire 800, unless you add packet security, heavy address range (ala I-SCSI), then it drops back to current EtherNet speeds.

The Opticis Company has prototyped FireWire technology ( http://opticis.com/product_8.htm ) making the equivelent of FireWire 3200 (4 X, multiple TI FW 800 chips) over two optical fibers, effectivly what might be ~~ = 40,000baseT. That's a bandwidth of greater than 320 MegaBytes per second (multiplexing w/various laser colors). The hook up to the computer is quite combersome, needing a copper snake of 16 twisted pairs plus shields and limited to a length of a little more than one meter. (The chief engineer tells me he can do better, but would have to build the bus interface inside the box, directly connected to the CPU buss = no copper conductors outside the box.) They did four channels of HDMI over two fibers with a range of a quarter mile last year and will release this quarter ... that's = RGB / HDTV plus multichannel 24 bit/48k ... times four.

So there are plenty of wide band technologies for audio at almost whatever bit rate & bandwidth per channel (64 bit / 192k = all eight THX channels times ten), as long as you are prepared to drop the metal conductors outta da equation and increase the number of ports.

All that is really needed is an acceptable standard as I2S, S/MUX, etc. seem to be falling short of the mark, mostly because of an inability to use more than one port at a time. (The perception is that there is a need for a "special" audio protocol, but this just puts a protocol on top of the hardware / firmware protocol. "Plain language", unencrypted FireWire is perfect for the task, but any peer to peer packet switching technology/protocol would do as long as someone doesn't insist of piling on something like iSCSI or SPDIF ... What's wrong with audio at 40 MegaBytes per second, unincumbered?)

Personally I think that a good happy medium would be four ports, each a 24 bit / 192k wide. Heck, plastic or glass fiber is cheaper than Teflon coated silver plated copper pairs ... No?

 

[FastEddy]

" ... I said bits, you said bytes. ..."

Above is all in 8-bit Bytes using packet switched addressing and checksum in the data packet.

 

[jwb]

You people have obviously never had to implement a FireWire interface. It's a massive hassle with huge, expensive, energy-consuming ASICs and quite a lot of firmware and protocol. Frequently you need a license for intellectual property or patents.

With plain LVDS on UTP, you just pipe bits in and they appear at the other end. You spend $5 total on parts. LVDS also has more than 50 times the required data rate.

I don't understand why you are proposing these other far more complicated schemes.

 

[FastEddy]

" ... You people have obviously never had to implement a FireWire interface. It's a massive hassle ... energy-consuming ASICs and quite a lot of firmware ... "

Ah, I have helped on a couple of these implementations on the hardward side. Yes there are licenses, too. No patents however since Apple put all of theirs into the public domain. As for the headache / heartbreak = check out this: http://www.oxsemi.com/oxford/documents/pages/audio/audio.html ... http://www.oxsemi.com/oxford/documents/support/OXFW971.html ... = http://www.m-audio.com/products/en_us/ProFireLightbridge-main.html ... Price it out = cheaper than trying to do 24 bit / 96k with USB.