This file is raw output from pdftotext and may not be ideal for distribution. If you are a maintainer for Hackipedia, please sit down when you have time and clean this text version up. Source PDF: /mnt/fw-js/docs/Hardware/AES, EBU digital audio interface/pdf/AES3 Channel Status Revisited (Article).pdf Like all conversions the text below should be fully readable as UTF-8 unicode text. --------------------------------------------------------------- AES3 Channel Status Revisited MARK YONGE MIBS continues and expands the discussion on the AES3 Interface. I was very happy to see Mike Law’s article, AES3 Byte 0, bit 0: Consumer/Professional mode Status Information – What is it For? in the How would you tell these two similar-but-different April/May issue of Line Up. Any 20 year-old high- formats apart? It was agreed that the first bit in the tech standard might reasonably be questioned, and first byte of the Status Data would indicate whether any considered critique of this little-understood the content of that Status Data conformed to the aspect of the world’s best-known professional digital professional (AES3) or consumer (IEC 60985-3) audio interface is useful (and sufficiently rare to be standard. This is arguably the most important bit in noteworthy in itself). I’m writing here, as a member the whole 192-bit Channel Status block. Hopefully, of the IBS, because I felt I ought to be able to put we’ve now got to: Confusion 0%, Importance 100%, some of Mike’s points into perspective. I did a little Usefulness 100% research and I’m also grateful to Robin Caine whose knowledge of the subject, and the history, is close to Byte 0, bit 1: Linear or Non-linear samples encyclopaedic. It turns out that some of the history It’s linear PCM audio unless you set this bit. This has is relevant. never been controversial. The AES3 standard for a professional two-channel digital audio interface emerged from the general Byte 0, bits 2 to 4: Pre-emphasis discussions about digital audio in the late 1970s and Twenty years on, the option for including HF early 1980s. There were a number of interested emphasis in PCM-coded audio does seem a little silly. parties. Some were interested in interfaces for CD However, at the beginning, many practical ADCs and players and future consumer equipment; others, like DACs were still 13-bit and 14-bit devices and the the EBU, were interested in professional applications noise floor was very apparent. HF emphasis was a in broadcast; a third group were interested in technique that had been used in FM radio, for professional equipment for music recording. The example, to ‘borrow’ HF headroom to improve HF Audio Engineering Society provided a forum for noise performance. However, this reckoned without these discussions. new forms of music with lots of HF energy – there was no headroom left to borrow – so emphasis Interface Divergence didn’t pay off! Now, with competent converters of Many interface issues were sufficiently general that 20 bits and higher, the technique is only a historical solutions could be adopted by all parties but, when it curiosity. came to the use of the Channel Status data block, the professional and consumer interests diverged. The Byte 0, bit 5: Nothing/Unlocked EBU and the AES, concentrating on professional This bit does not and cannot mean Locked vs applications felt strongly that the channel status data Unlocked. The fact that the transmitting device feels should be used to support a range of options cosy about being locked has little meaning for the potentially important to professional users. The receiving device that may not have access to the consumer group had a different agenda. same clocks. However, setting this bit could be As a result, not one but two standards emerged. useful in planned situations to indicate that a device The frame and subframe of the data stream, the had lost its reference, including the Digital Audio block structure for additional data, and the PCM- Reference Signal (DARS) unit which might become coded audio data itself, was similar in both cases. unlocked from its parent video reference. The AES and the EBU defined a set of Channel Status parameters with checksum protection to avoid Byte 0, bits 6 to7: Sampling Frequency corrupted status data. IEC 60958-3 (aka S/PDIF) The need to state a sampling frequency was more defined a simpler scheme, without checksum necessary before dedicated silicon came into use and protection, to support copyright management. Let’s everyone had to design their own logic (remember look again at the important parts of that block of 192 TTL?). With the use of over-sampling DACs there was bits of status data that are repeated every 192 easier indication from the clock rate than from samples. channel status. It was useful when a digital reel-to- reel was started at the wrong speed, giving 48kHz when the original was 44.1kHz. Then the channel status would set the error lights flashing. 20 LINE UP June/July 2005 Byte 1, bits 0 to 3: Channel Mode ‘Minimum level’ of channel status so that This illustrates nicely why there are two separate professional receivers would accept this audio. channel status streams, one in each channel. AES3 is ‘Standard level’ was what most users required, with a two-channel interface and there is no guarantee ‘Enhanced’ implementation available for those with that both channels will be similar, or even related. such needs. The items mentioned above comprise For example, one could be PCM-coded audio, the the AES3 ‘Standard Implementation.’ All other bytes other some different type of data. In router are optional, and basic functionality should be management the two channels can be, and often are, independent of them. split and routed independently. The Future Byte 1, bits 4 to 7: User Bit Management In the early days, the structure of channel status was User data has not been used to any great extent to largely formed by the difficulty of designing logic to date, however the apparent thirst for metadata in the perform the decoding. Many early decoders ‘cherry- broadcasting community at least, suggests that its use picked’ the channel status bits of interest and will increase. For example, one project currently ignored the rest – rather than parsing the bitstream being developed (AES-X111) proposes that User Bits properly starting at byte 0 – causing some obvious may carry a unique identifier for the associated audio problems. stream, potentially handy for relating any amount of The AES is not a policeman – AES standards are external metadata to a specific audio source. Press voluntary – and requirements in the standard will the Red Button now! never stop silicon manufacturers selling whatever they can. However, if a chip or a piece of kit claims Byte 2, bits 0 to 2: Aux Bits ‘AES3’ but doesn’t comply with the standard, The BBC formalised a use for Aux bits, though they someone ought to point this out – to the supplier at possibly never used it. There was also a suggestion of least. putting the four protection bits from a Hamming AES3 may support more complexity than any one 11,7 code to error-correct the seven MSBs of the application may need, and certainly the predictions sample into the Aux bits – errors below the first of 1985 have led to some redundant features and a seven MSBs have lower perceptibility than wish-list of alternative definitions. However, much of concealment mechanisms. This scheme was never it is used and the standard is still being expanded to formalised. support new requirements such as higher audio sampling frequencies and modern metadata schemes. Byte 2, bits 3 to 5: Word Length Not bad for a 20-year-old digital document, and it’ll The design of the scheme meant that failure to read stay useful for as long as good people help to keep it these status bits was never catastrophic; even the up to date and users appreciate its usefulness and accidental playing out of Aux data would be at a very dependability. low level. In fact the default of 20 bits was safe, if not purist. Byte 2, bits 6 to7: Alignment Level The IABM asked AES Standards to implement these two conditions because of potential problems with Further Reading videotape interchanges between European and US In addition to AES3-2003: Serial transmission users. The AES standardised the channel status flags format for two channel linearly represented simply to indicate the use of two established digital audio data, the AES publishes two practices standardised elsewhere (EBU R68 and information documents intended to help those SMPTE RP155). implementing the AES3 interface. They are, AES-2id: Guidelines for the use of the AES3 Byte 23, bits 0 to 7: CRCC interface, and AES-3id: Transmission of AES3 This was never meant to indicate transmission errors, formatted data by unbalanced coaxial cable. All still less that there was a problem with the audio. It these documents are available for download at merely shows that a block of channel status data has www.aes.org/publications/standards/ been corrupted; by editing or switching for example. The AES Historical Committee has put together an archive of early digital standardisation reports Implementation which will illuminate the early development One of the biggest issues in completing the 1985 process. Go to www.aes.org/aeshc/ and click on standard was the need to specify three levels of Digital Audio Engineering Standardization implementation. The ‘Minimum Level’ simply read History at the AES. Byte 0 bit 0 to determine whether the bitstream was AES Standards general information is at: professional or consumer. This requirement was www.aes.org/standards/ The IEC 60958 (part 3) demanded by manufacturers who were unwilling to Digital audio interface: Consumer applications is incur the cost of implementing real channel status available from www.iec.ch/ because they were actually thinking in consumer terms. The committee was forced to include this 22 LINE UP June/July 2005