AES/EBU, S/PDIF, and ADAT signal family relationships?
Feb 25, 2006 at 4:16 PM Thread Starter Post #1 of 4

slwiser

Headphoneus Supremus
Joined
Jun 23, 2001
Posts
6,317
Likes
24
I did not know exactly where to place this question. It is related to the signal from computer as a source so I am asking it here.

What are the family relationships between AES/EBU signal and the S/PDIF signal? ADAT signal? How do these signals compare concerning jitter? Signal strength? RF interference? etc.

I found this link which attempts to explain some of this but I would like it if someone could put this into more layman's terms for me.

http://emusician.com/mag/emusic_spar...nge/index.html

Note that these partial paragraphs are interesting to me:

"The AES/EBU format is self-clocking: word clock is embedded in the digital audio stream. As a result, a single cable carries two channels of audio plus word clock. However, master-clocking AES/EBU devices is also possible and even recommended in larger, more complex systems."

"As with AES/EBU, S/PDIF word clock is carried in the digital audio bit stream. However, S/PDIF devices don't typically come with separate BNC word-clock connectors, so they can't be configured for a master-clock system."

If this is so then would the AES/EBU has an inherent advantage over the S/PDIF signal while on coax or lighpipe? While the article states that the AES/EBU signal is self clocking it does not clearly state that the S/PDIF is? Suggesting an advantage to me? What am I missing?

Then there is ADAT: "The ADAT Optical format uses an embedded clock signal that does the same job as standard word clock." How does this compare as a primary signal with AES/EBU and S/PDIF practically?

Example: If I have a sound card (i.e., REM Digi96/8 that is capable of any one of these signals moving data over a AES/EBU 100 ohm cable with XLR connectors to a Lavry DA10 into its AES connector) would the AES/EBU signal be self clocking and the Lavry's internal synchronous dejitter mechanism read that clock negating any potential jitter?

Now for a can of worms; would this setup with its embedded word clock feeding a device able to read that clock be an equal to using an I2S signal using an Off-Ramp into a DAC that can handle the I2S signal?

I know, several to many questions? But questions I have been attempting to finds some answers too.

Thank you for any information/clarifications that you can provide.

You can see my sig for my bias and context for asking these questions!
 
Feb 26, 2006 at 12:20 AM Post #2 of 4

dip16amp

100+ Head-Fier
Joined
Dec 17, 2003
Posts
430
Likes
10
The AES/EBU and S/PDIF formats both have word clock in the digital audio stream (self-clocking). The RME Digi96/8 PAD can send either format to any of it's physical interfaces (XLR, coax, toslink).

The RME card has an optional word clock module for an external BNC connection but a DAC with an external word clock connection would be needed to use it.

The main difference between AES and S/PDIF is the physical interface. The RME AES interface is 3.5 volts for a balanced 110 ohm cable and XLR connector. The RME S/PDIF is 0.8 volts for an unbalanced 75 ohm coax cable and rca connector. The AES cable maximum distance is listed as 100 meters and the S/PDIF cable maximum distance is listed as 10 meters.
 
Feb 26, 2006 at 12:40 AM Post #3 of 4

slwiser

Headphoneus Supremus
Joined
Jun 23, 2001
Posts
6,317
Likes
24
OK, now that made it sound a lot simpler than the other stuff I have been reading. Concerning the quote below, are the embedded word clocks in the AES/EBU and S/PDIF signals equal in their ability to be decoded by a DAC on the receiving end? Or does one have an advantage?

Is the external word clock plus dac that handles this extra word clock equal the I2S interface? Or does one of these have an advantage?

Thanks for your response.

Quote:

Originally Posted by dip16amp
The AES/EBU and S/PDIF formats both have word clock in the digital audio stream (self-clocking). The RME Digi96/8 PAD can send either format to any of it's physical interfaces (XLR, coax, toslink).


 
Feb 28, 2006 at 10:40 PM Post #4 of 4

slwiser

Headphoneus Supremus
Joined
Jun 23, 2001
Posts
6,317
Likes
24
Note that for I2S there appears to be a jitter specification and it seems to be the same as that for the S/PDIF specification of 75ps. I found a reference to this somewhere. Jitter will exist in both formats, no getting around it, the devil is in the details, design and execution of design.

I got this summary from Dan Lavry for a set of similar questions that I posted above:
__________________________________________________ ____

It is always helps to keep the physical cable and connector separate from the digital format of the signal.

AES and SPDIF are somewhat different formats, but they have a lot of similarities. The concept of clock extraction is very similar. From a hardware standpoint, the AES signal is around 2-5V (peak to peak)into 110 Ohms and the SPDIF is only .4V into 75Ohms. So the AES is signal has at least times the power of SPDIF (typically 40 times). That makes the AES more robust and more suitable for long cable runs.

In addition, the AES has a transformer coupling (a transformer in the signal path), and AES/EBU has 2 transformers, one at the driver side, the other at the receiver side. The transformers helps to decouple (separate) the grounds of various units. It also makes the transmission differential (balanced) so it does offer some advantages, certainly for long cable runs.

As a rule, an XLR carries AES signal format, and a coaxial carries SPDIF signal, but that is getting to be more of a historical fact. Many people use coaxial connection for AES and XLR for SPDIF.

Optical (toslink) is also capable of carrying either format. It was designed for SPDIF, but it can handle AES.

ADAT is another format, not compatible with AES or SPDIF. The ADAT is some multi channel format designed for optical link. It is less common then AES or SPDIF.

All the previously mentioned formats are single wire interface (though they carry at least a stereo signal, clock information plus some auxiliary data).

But once you look at an IC, say an AD or a DA, or a DSP, there comes a need to feed such IC's with more then just one serial signal stream. A typical DA IC would require data (possibly stereo), and a clock running at the sample rate, and also a clock running at say 64 times the sample rate, and yet another clock running at 256 times the sample rate...
This was just an example. Some IC's would expect 128 or 384 ratios... the point is that direct communication with and IC may require "separating” an AES or SPDIF into its "components" (3 or 4 signals). An AD will typically require rearranging such signals into a single data stream.

Now, the job of interfacing the internal DA or AD or sample rate converter, or a DSP... into or out of a single wire format is most often done by use of digital audio receivers and digital audio transmitter IC's.

There are a number of "internal format" (the separated data and clocks signals). There is a "left justify" format, there is a "right justify" format, there is "I2S format".

Interfacing via I2S does not make any sense to me. I realize that some company is selling such gear, but that format is designed for internal use. Having say 4 long wires between say a DA (or AD) carrying I2S can be big trouble, long wires (including drivers, imperfect terminations, receivers) is a receipt for picking up a lot of jitter. The usefulness of such arrangement calls for VERY SHORT INTERCONNECTIONS, typically a few inches of printed board trace length.

It is true that a single long wire carrying a signal is equally susceptible to jitter, but the better the gear, the better the jitter removal circuitry. I see no advantage to having 3 cables (I2S) over a single cable. In both cases you depend on the internal circuitry to remove jitter.

Regards
Dan Lavry
 

Users who are viewing this thread

Top