AES/EBU VS SPDIF

[techristian]

I don't understand how a DIGITAL signal can be different. If you send 0100100010101111 ,your stereo should play 0100100010101111 unless we are talking 24 bit vs 16 bit .

 

 

 

DAN

[Phil O'Keefe]

Here's a page with lots of information that you may find helpful...

 

http://www.rane.com/note149.html

 

 

[MikeRivers]

I don't understand how a DIGITAL signal can be different. If you send 0100100010101111 ,your stereo should play 0100100010101111 unless we are talking 24 bit vs 16 bit .

 

That Rane tech note is a pretty good description of the differences between the hardware interfaces (Rane tech notes are pretty good no matter what subject they're on), and really, that's the difference between S/PDIF and AES/EBU. It's like the difference between balanced and unbalanced analog connections. The same information goes through both connections just fine, but in most cases, a balanced connection is more robust and less susceptible to outside interference. You know about hum and buzz and interference from nearby radio and TV stations.

 

In the digital world, interference is primarily related to the timing stability of the bit stream. The data goes out at a (hopefully) accurate clock rate that's hopefully synchronized on the receiving end. When the When the transmitted data stream changes from a 1 to a 0 and vice versa, the receiver knows when there's supposed to be a data bit and if the clock drifts off or something in the path causes a delay, the receiver can misread an occasional transition and you get a click out of the D/A converter.

[techristian]

Thanks everyone. I guess that I was expecting BUFFERING at the receiving end and some sort of checksum.

 

Dan

[MikeRivers]

Thanks everyone. I guess that I was expecting BUFFERING at the receiving end and some sort of checksum.

 

There's some of that, but it's not AES/SPDIF-dependent. There's a parity check in the bitstream and a "validity" bit that tells the device reading the data whether the sample value contained in the data frame is valid or not. This bit is usually what's used by a CD player to tell it to either mute (if there's a bunch of consecutive frames with invalid data) or to conceal the error by substituting the preceding sample value for the one with the possible error.

 

There's always buffering. In the software, you know it as the thing that causes latency (though there are plenty of other things that contribute to the total throughput delay). And some devices, particularly those that connect a digital audio interface to a computer via USB, also have a hardware buffer for what comes through the USB port since the rules of USB transfer allow it to be interrupted if the computer needs to do something else.

 

A complete audio file (like for a whole song) usually has a checksum, but that's part of the file format, not the gozinta-gozouta interface hardware or firmware.

 

 

[techristian]

ok