The ST 2110-3x series of standards describe how to deliver digital audio within an IP studio. There are currently only two parts relating to uncompressed audio. Their payloads are described by AES3 and AES67, hence the SMPTE standards themselves are quite brief.

• AES3 - Describes a simple two channel stereo streamed transmission. Deployed as ST 2110 Part 31.
• AES67 - Adds more channels and improves the performance. Deployed as ST2110 Part 30.

Those standards are based on many other AES documents on related topics. Study them all to understand the complete picture. These are the most important but they do refer to others:

• AES5 - Preferred sample frequencies.
• AES11 - Synchronization of digital audio equipment.
• AES18 - Ancillary user data channel format.

The Audio Engineering Society (AES)

The Audio Engineering Society was established in 1948. They produce standards and guidelines for audio engineers. Annual conventions are currently organized every year in Europe, the USA and Latin America. The technical papers are collected into a proceedings volume and selected papers are published in the member’s journal. The individual papers are easily obtained from the AES Electronic Library.

The AES works closely with the European Broadcasting Union (EBU) and provides input to the ISO/IEC standards bodies.

AES3 - Serial Transmission For 2-channel Digital Audio

This standard describes how to transmit 2 channels of digital audio over a variety of different mediums. The supported audio format is linear Pulse Code Modulation (PCM) which is an uncompressed stream of samples. Sample sizes between 16 and 24 bits are supported. Other formats are possible but not described by AES3. See AES5 for the list of acceptable sample rates.

AES3 comprises four separate parts:

AES/EBU is described in the third edition of the EBU Tech 3250 document.

AES67 - High-Performance Streaming Audio-Over-IP Interoperability

The original intent for AES67 was to deliver professional quality audio over a high-performance IP network with less than 10 ms latency. Bridging diverse pre-existing audio networking systems to provide interoperability is also a core goal. This is suitable for sound reinforcement at live events.

High performance is feasible on existing local area networks (LAN). If suitable switching hardware is available, it can be supported widely across an enterprise.

These are the main features:

• Based on existing and well-known IT standards described in IETF RFC documents.
• Synchronization with boundary clock converters.
• Streaming transport via RTP.
• Session description with SDP.
• Low-latency delivery of uncompressed audio.
• Ideal for live, studio and broadcast situations.
• Decentralized configuration and management of devices.
• Coexists with other IT data traffic on the same network.

Prior to AES67, the available audio networking solutions were incompatible with one another. AES67 is designed to reconcile the needs of architectures designed by different manufacturers and facilitates interoperability between:

• Dante.
• Ravenna.
• QLAN.
• WheatNet-IP.
• Livewire.

These topics are addressed by the standard:

Transport synchronization - A variety of techniques are discussed in Section 4 of the standard.

Media profiles - Standard IP networks must adhere to a media profile (see Annex A) to ensure timely delivery of packets.

Boundary clock converters - Networks using switching hardware that supports IEE PTP protocols can provide boundary clock conversion and should provide adequate performance for audio delivery.

AVB - Enhanced Ethernet Networks that conform to IEEE 802.1Q are described as Audio Video Bridging (AVB) and provide synchronization based on IEEE PTP. This is covered in Annexes C and D.

Media clocks - These are described in Section 5 and provide synchronization at the sample level. A media clock advances in sync with the sample rate. The same frequency should be used for the RTP clock.

Payload encoding - This is described in Section 7, which reiterates the limited range of three preferred sample rates from AES5 with two possible sample sizes. Packet sizes are determined primarily by how long the data in them would play for the given sample rate. AES67 describes these sample rates (derived from AES5):

• 48 kHz.
• 96 kHz.
• 44.1 kHz.

The standardized sample sizes and formats are defined in great detail in these IETF RFC documents:

• L16 - 16-bit linear format as defined in RFC 3551 clause 4.5.11.
• L24 - 24-bit linear format as defined in RFC 3190 clause 4.

Channel count - Up to 120 channels of audio can be carried in a generic AES67 link. ST 2110-30 limits the number of channels depending on the conformance level of the receiving device. This may be as low as 4 channels at level AX and not more than 64 for level C.

SDP - Session Description Protocol provides discovery and connection management support. This includes keep-alive heartbeats to maintain connections. The discovery systems are described in Annex E. These include the AMWA NMOS IS-04 specification used by ST 2110.

IETF RFC references - Because this is a standard describing IP network transmission, there are many RFC documents cited in the normative references in Section 2 of the standard and more references are included in the bibliography in Annex H. Using the IETF specifications ensures compatibility with the rest of the IP network traffic.

AES5 - Preferred Sample Frequencies

This standard describes various sample rates and recommends 48 kHz at the outset because it is numerically easier to convert this to other sample rates. See Section 4.2 of the standard for an explanation. Sample rates at 96 and 44.1 kHz are also described.

There is an interesting paragraph on bandwidth (see Section 4.1) based on the Nyquist-Shannon sampling theorem.

Derived sample rates ranging from half to 8 times the basic sample rate are also described. There are tables listing the number of samples per frame of video at different frames per second rates vs. audio sample rates.

This is an important foundational standard referred to by AES3 and AES67 and other related documents.

AES11 - Synchronization Of Digital Audio Equipment

Multiple channels of audio must be carefully synchronized. The sample clocks governing when the source audio is captured must be accurately regulated. Any downstream processing needs to maintain the phase relationships between channels to avoid introducing unwanted audible artefacts. This is a complex topic and there are many solutions.

Equipment having an internal sample clock must be locked to an external source. AES11 describes this as a Digital Audio Reference Signal (DARS) which is delivered separately from the audio content (usually via a separate connection). AES5 describes multiples of (up to 8 times) the basic sample rate. The internal sample clock must be capable of reliably locking to all of these.

Alternative synchronization techniques can be used instead of DARS:

• Embedded time signatures based on the packet header timestamps. This may drift out of sync with other streams.
• Video reference syncing to frame start events.
• GPS locked. This requires a separate receiver device and locks to real-world time.

AES11 describes the word clock (see Annex B). This synchronizes hardware devices (such as digital tape machines or CD players). The word clock governs the timing of each sample passing through the system and is derived from a centralized reference. This will be familiar to broadcast engineers who ensure that video across an enterprise is frame synchronous by distributing sync pulses from a reliable source.

The word clock is not the same as timecode. The word clock is integral to the sampling process and transmission of the digital audio where the timecode is a separate metadata service that describes the media being transmitted.

AES11 refers to AES5 and augments the sample rate descriptions with advice pertaining to video reference timing.

AES18 - Ancillary User Data Channel Format

Ancillary user specified metadata can be embedded within an AES3 audio stream. Messages can be any length. The only limitation is the maximum bitrate which caps the amount of data that can be inserted in addition to the audio payload. A long message could describe the entire asset with an abstract for display in an EPG. Shorter messages provide synchronous data such as:

• Subtitle text.
• Script cues.
• Editing information.
• Copyright assertions.
• Performer credits.
• Downstream switching instructions.

This is managed carefully to avoid delaying the audio content. Messages can be split and portions deferred to accommodate the bitrate capping limit.

Ancillary data adapts the High-level Data Link Control (HDLC) protocol originally defined in ISO 3309 (as defined in AES18). That standard has now been withdrawn and replaced by ISO 132239. HDLC is bi-directional, but in the context of AES3, the messages only travel one way with no handshaking.

Error resilience helps detect data corruption at the receiver. If necessary, important data could be delivered in a carousel-like structure and repeated periodically.

The standard lists many external references in the Annex C Bibliography. These date from the mid 1980's to the 1990's and cover radio text services which are now deployed worldwide. Because of the vintage, the specified character sets do not yet use Unicode. Text is constrained to 8-bit character codes as defined in ISO 4873. UTF-8 character encoding of Unicode text is briefly mentioned in the AES67 standard.

ST 2110-30 - RTP Streamed PCM AES67 Audio

The ST 2110-30 standard describes how to deliver uncompressed AES67 audio via RTP streams in an IP based studio. The delivery is supported by signaling metadata delivered using the Session Description Protocol (SDP). This metadata is necessary to receive and correctly interpret the stream.

SMPTE ST 2110-30 can be seen as a subset of AES67. Most of the requirements for stream transport, packet setup, and signaling are common to ST 2110-30 and AES67. ST 2110-30 profiles AES67 with these constraints to ensure more reliable interoperability:

• Support of the PTP profile defined in SMPTE ST 2059-2 instead of that defined in AES67.
• An offset value of zero between the media clock and the RTP stream clock.
• Mandatory signaling to force a device to operate in PTP slave-only mode.
• Support of IGMPv3 for multicasting. Refer to RFC 3376 for details.
• RTCP messaging is tolerated but not mandated or required.
• Receivers need not support the Session Initiation Protocol (SIP) or other connection management support.
• The size of UDP datagrams (packets) is specified in ST 2110-10 and supersedes those in AES67.
• SDP channel ordering syntax must follow RFC 3190 conventions.
• The maximum number of channels is limited depending on the conformance level.

The AIMS Alliance has published a helpful white paper that describes how ST 2110-30 and AES67 interact. Download a copy of AES67-SMPTE-ST-2110-Commonalities-and-Constraints here:

Channel Ordering

Channel ordering is described in a Session Description Protocol message with symbolic names. The receiver can use them to deduce how to unpack the received samples and reconstruct the correct channel mapping. If this SDP description is omitted the receiver will assume all channels are of an undefined type:

Conformance Levels

ST 2110-31 - AES3 Transparent Transport Over RTP

Relevant Standards

These are the relevant standards you need to fully explore ST 2110-30 and ST 2110-31. The version indicates when they were revised or in the case of AES standards reaffirmed as being up to date. Note that the AES standards refer to some IEC standards that are more often identified as ISO standards. Where standards are superseded, the original reference (from AES or SMPTE) and the replacement standard are listed. The version column lists the most recent edition, amendment or reaffirmation of a standard:

Conclusion

The ST 2110 and AES standards described here convey uncompressed digital audio around an IP network. Compressed audio formats such as AAC are currently outside the scope of these standards.

Although AES67 is an open standard, patent licensing may be necessary if you are designing a commercial product based on it. The principal patent holder is an Australian company called Audinate Pty Ltd. There may be other relevant patents that AES are unaware of.

The AES and SMPTE standards are easier to read and understand than MPEG standards. They tend to be much shorter and focused on a specific topic. They are very dependent on other earlier documents. SMPTE, AES and IETF RFC documents frequently refer to each other.

IETF standards are available online to download free of charge. SMPTE and AES standards are free downloads for subscribing members. Joining both societies is easy and worth the subscription fee if you intend purchasing more than a couple of their standards.

These Appendix articles contain additional information you may find useful: