[sdiy] S/PDIF

Sat May 15 04:57:57 CEST 2004

Hello Julien,

It's a rather interesting coincidence that your question came through the 
mailbox at almost exactly the same time as this week's Sweetwater Sound InSync 
mailing, which actually contained a fairly in-depth description of the IEC958 
standard.  I have copied and pasted that article into this mail.  I hope the 
large mail size doesn't offend anyone, and I apologize in advance if it does.  
There are some links for further info at the end of this.  I hope you find this 
useful.

Michael Bacich

----------------------------------------------
(from Sweetwater InSync, May 14, 2004)

Today we are going to break apart the digital data that is 

transmitted in IEC958 connections. Once we do this the difference 

between IEC958 Part 3 (S/PDIF) and IEC958Part-4 (AES3) should be 

apparent.

Here goes...

It's important to remember that IEC958 (including AES3, S/PDIF, etc.) 

is a serial protocol - all of the data is transmitted bit by bit, 

serially. Each "sample" (or frame) of audio data transmitted consists 

of two subframes: one for the left channel and one for the right. 

Each subframe is made up of 32 bits of data - or you could say it is 

a 32 bit word. These 32 bits break down as follows:

    * Bits 1-4: The first four bits are used for synchronization data 

(sometimes referred to as a preamble). This is not sync like time 

code - this sync data tells the receiving device where each channel's 

data begins (remember, it's a serial transmission) as well as some 

other stuff we'll talk about below).

    * Bits 5-8: Technically these bits are for "Aux Data," but when 

transmitting 24 bit digital audio they get used for the four least 

significant bits (LSB) of audio data. If the digital audio data is 20 

bits or less they can be used for other things, but usually aren't.

    * Bits 9- 28: Digital audio data, transmitted LSB first, MSB last.

    * Bit 29: Validity - tells whether audio data is fit for conversion.

    * Bit 30: User Data - some machines let the user encode small 

amounts of data in the transmission, such as date, reel number, etc.

    * Bit 31: Channel Status Data - See below.

    * Bit 32: Parity Bit - The first layer of error correction/detection.

For the most part this is all pretty straight forward, however, bits 

30 and 31 have some interesting properties. While only one bit of 

data is transmitted per sample (each channel has its own unique User 

and Channel Status Bits) they are each accumulated over a period of 

192 samples (or frames) and used to construct a data block that is 24 

bytes of 8 bit data (do the math - that's 192 total bits of data). 

These 192 frame blocks are separated and denoted by unique preamble 

data (bits 1-4 above). Each time a certain configuration of bits is 

seen in positions 1-4 the receiving machine knows to begin 

accumulating Channel Status and User Bit data again.

It is the data contained within the 24 Bytes of the accumulated 

Channel Status data (bit 31 above) that we are interested in. The 

Channel Status bit carries all kinds of information that is used to 

further specify the nature of the digital audio data being 

transmitted. This includes things like sample rate, emphasis, bit 

depth (thus defining how bits 5-8 above are used), SCMS info, CRC 

error correction data, and a whole bunch of other minutiae.

The very first bit of this data (also he first bit of the first byte) 

is known as the 'PRO' bit. It determines the definitions of many of 

the bits to follow. The key point to understand here is that some of 

the data mentioned in the paragraph just above this one will be 

different depending upon the status of this bit (one or zero). If 

this bit is a one, then it defines the data as a 'PRO' transmission. 

It configures the following 7 bits like so:

    * Bit 2: Audio bit - defines whether the data is standard audio 

data or some other type.

    * Bits 3-5: Emphasis - Tells whether emphasis is enabled, and if 

so, what type.

    * Bit 6: Lock - whether the data is locked to the source's sample 

frequency.

    * Bits 7 & 8: Fs - Information about the sample frequency.

This is just the first byte of data that gets constructed from the 

192 bits of Channel Status data. We'll not go through the rest of 

it - you can assume a lot of it is similar types of information.

Now...if that 'PRO' bit is set to a zero, the meanings of some of the 

subsequent bits are changed. Let's look at bits 2 though 8 of the 

first byte of data in a "consumer" transmission (remember, the first 

bit is the 'PRO' bit itself) and compare it to the structure just 

above:

    * Bit 2: Audio Bit - same as before.

    * Bit 3: Copy Bit - This is the first bit of the infamous SCMS 

copy protection code. (The other bits of SCMS are part of Byte #2).

    * Bits 4-6: Emphasis - Pretty much like bits 3-5 in 'PRO' mode, 

but they have some different specific designations.

    * Bits 7 & 8: Mode - Defines the meaning of some following Bytes, 

which we're not going to get in to.

Okay, by now you have enough information to begin to see the problem 

yesterday's inSync reader is having. In the broad definition of 

IEC958 there are two fundamentally (though subtly) different 

configurations of data. In the portion we've laid out above you can 

see that one of the SCMS bits in the consumer format overlaps with 

the emphasis data in the 'PRO' configuration.

Now, as goofy as this sounds at face value they are actually 

implemented in such a way that a true conflict shouldn't happen 

(though there are some rare conditions where emphasis can erroneously 

be indicated). There are, however, other changes throughout the 

following bytes of data. In 'consumer' mode a lot of the following 

data is not used (or is mapped intelligently) so under most normal 

circumstances a conflict is not likely to occur. That said, the two 

different formats of data are 'technically' not compatible with one 

another. They are two different formats that just happen to be able 

to co-exist most of the time.

Many professional audio devices are capable of recognizing the status 

of the pro bit and configuring themselves accordingly, or will allow 

the user to manually change a setting to determine how the data is 

used (or transmitted). Many other machines may simply ignore it. Many 

consumer devices will ignore it as well, but some, if unable to 

reconfigure themselves, will simply refuse to recognize the 'pro' 

data. It would be very unusual for a consumer designated device to 

give the user access to this setting manually as that, by definition, 

is a feature reserved for pro devices. It is also possible for a pro 

machine to refuse to recognize consumer configured data, and to have 

no way to be reconfigured, though in practice that would be quite 

rare.

Okay, now that we understand this, what can we do about it? 

Unfortunately the answer is relatively little. The first thing to do 

if you run into a situation where this is a problem is call the 

manufacturers of the two devices and see if there is any way to 

effect a change to either one of them (in software or firmware) that 

will enable them to become compatible. If that proves to be a dead 

end about all you can do is swap out one of the devices for something 

that will be compatible. A third solution is to purchase a device 

that is capable of either reconfiguring the data, or at least 

changing the status of the 'pro' bit so that the receiving device can 

be "tricked" in to thinking it is getting the right kind of data. 

This actually works pretty well, but the relatively few devices that 

do this can be somewhat expensive. Your Sweetwater Sales Engineer can 

help you through this if you think you are having a similar problem.

One added caveat or potential layer of confusion. These 'standards' 

are all in flux to some degree. Things do change from time to time, 

though usually not in ways that have much consequence to end users. 

We also have to remember that a standard is not much more than a 

voluntary statement of common industry practices. A given 

manufacturer's compliance with these standards is, A) voluntary, and 

B) subject to their interpretation of the standard itself. And there 

is room for subtle differences in the interpretation of some parts.

_____________________

- sweetwater archives - 

http://www.sweetwater.com/click/is_051404/dinsync/?find=05/11/2004

- IEC958 - http://www.sweetwater.com/click/is_051404/wIEC958

- IEC958Part-3 - http://www.sweetwater.com/click/is_051404/wIEC958Part-3

- S/PDIF - http://www.sweetwater.com/click/is_051404/wS/PDIF

- IEC958Part-4 - http://www.sweetwater.com/click/is_051404/wIEC958Part-4