The ST 2110-3x Documents

The ST 2110-3x group of standards describe how to deliver digital audio within an IP studio environment. 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 ST 2110 Part 30.

AES3 and AES67 are based on and refer to many other AES documents. Study them all to understand the complete picture. These are the most important but there are others:

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

SDI Audio Embedding

ST 2110-2x standards accommodate SDI conforming to the ST 292 standard as a source format. SDI has the capacity to carry up to 16 channels of audio depending on the sample size and frequency.

The SDI format is derived from classic analog TV services, having a space in the line structure where the video is blanked. Each horizontal line has a space at the start for ancillary data (HANC). Lines are reserved at the top and bottom of the frame for more ancillary data (VANC).

Digital audio is stored in the HANC space and is extracted for conversion to MPEG or ST 2110 compatible formats.

ST 2110-30 – RTP Streamed AES67 Audio

The AES67 standard describes Pulse Code Modulated (PCM) audio. ST 2110 Part 30 describes how to package uncompressed AES67 samples into RTP packets for transport on the IP network.

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.

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 follower-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:

The audio is extracted from the Horizontal Blanking data space which carries audio signals and other ancillary data as well. Only the audio is encapsulated in the Part 30 elementary stream.

The number of supported channels can range from 1 to 64 depending on the timing of the packets and the sample rate:

• SDI can only accommodate 16 channels.
• A default sample-rate of 48 kHz is mandated. The only other alternatives are 44.1kHz and 96kHz.
• Sample sizes of 16 or 24 bits are supported.
• A packet time of 1ms or 125µs is allowed.
• Packet time and sample-rate determine how many channels can be carried.

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 an undefined type. Sending the correct channel configuration facilitates the delivery of surround-sound multi-channel audio. Multi-channel mapping is managed by the Channel Order Convention delivered via an SDP message. The following types are supported:

Because an incoming SDI feed can only deliver 16 audio channels, the 222 symbol cannot be used. Neither can undefined group values U17 to U64.

Note that the channel ordering can be stacked. This example SDP fragment describes the first six channels as 5.1 surround format and the next two as a stereo-pair delivered alongside them:

This second example SDP fragment describes the first four channels as separate monophonic channels, and the next two channels as a stereo-pair and the last two channels as an undefined type:

Conformance Levels

The ST 2110-30 standard describes receiver conformance levels that determine how the incoming packets will be reassembled into channels.

This is based on the sample rate vs. the packet times. The multiple of these determine how many channels can be carried within the available capacity. If the chosen level limits the number of channels to less than you need, multiple AES67 links can be delivered with the channels sensibly divided between them. If all 16 channels are arriving in an SDI stream but your receiver is only able to support Level A (as specified in the table), you will need to transmit eight channels in each of two separate AES67 links running side-by-side.

There are three basic conformance levels. Extended variants sacrifice the maximum channel count to allow larger sample rates:

Level A is mandatory and must be supported by all receivers. This is also defined in AES67 as the minimum support. These are all based on 24-bit samples.

Levels B & C support shorter packet times to improve latency. They also support more channels for interoperability with MADI (AES10) systems.

Levels AX, BX and CX add support for 96 kHz sample rates but reduce the number of supported channels where necessary.

For example, conformance level CX can reconstruct 32 channels of 96kHz audio when the packets are spaced at 125µS intervals but if the sample rate is reduced to 48kHz, it can then support 64 channels. Packet spacing at 1ms intervals is exactly eight times slower and the maximum number of channels should therefore be divided by eight to compensate.

ST 2110-31 – AES3 Transparent Transport Over RTP

The ST 2110-31 standard extends ST 2110-30 to describe real time, RTP-based transport of any audio format that can be encapsulated into AES3.

The RTP packet header and payload format is described in Section 5. Packets are synchronized to a network reference clock described in ST 2110-10. Session Description Protocol (SDP) messages describe how the payload is constructed for the benefit of the receiver. See Section 6 of the standard.

This is all based on the original Ravenna AM824 specification and registered with the IANA as RTP Media Type ‘AM824’. Refer to RFC 4855 and RFC 6838 for details.

Annex A of the standard describes how AES3 and AES10 (MADI) protocols interact. They are broadly compatible but some data needs to be correctly framed and some flag-bits must be adjusted within the packets as they move between the two environments.

SMPTE standard ST 337 is an earlier but still relevant general-purpose encapsulation format for AES3 payloads. There are 32 basic data-types described by ST 338. The ST 337 payload format can be extended to support additional data-types. The payloads can carry audio and other kinds of data. 

Here are a few of the supported data-types:

Note that you may need to deploy hardware coding in order to reduce the latency sufficiently to use MP3, AAC and HE-AAC codecs for the audio.

Relevant Standards

These are the relevant standards you need to fully explore ST 2110-30 and ST 2110- 31. The vintage column 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:

Applying AES & ST 2110-3x Standards

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: