AES67


AES67 is a technical standard for audio over IP and audio over Ethernet interoperability. The standard was developed by the Audio Engineering Society and first published in September 2013. It is a layer 3 protocol suite based on existing standards and is designed to allow interoperability between various IP-based audio networking systems such as RAVENNA, Livewire, Q-LAN and Dante.
AES67 promises interoperability between previously competing networked audio systems and long-term network interoperation between systems. It also provides interoperability with layer 2 technologies, like Audio Video Bridging. Since its publication, AES67 has been implemented independently by several manufacturers and adopted by many others.

Overview

AES67 defines requirements for synchronizing clocks, setting QoS priorities for media traffic, and initiating media streams with standard protocols from the Internet protocol suite. AES67 also defines audio sample format and sample rate, supported number of channels, as well as IP data packet size and latency/buffering requirements.
The standard calls out several protocol options for device discovery but does not require any to be implemented. Session Initiation Protocol is used for unicast connection management. No connection management protocol is defined for multicast connections.

Synchronization

AES67 uses IEEE 1588-2008 Precision Time Protocol for clock synchronisation.
For standard networking equipment, AES67 defines configuration parameters for a "PTP profile for media applications", based on IEEE 1588 delay request-response sync and peer-to-peer sync ; event messages are encapsulated in IPv4 packets over UDP transport. Some of the default parameters are adjusted, specifically, logSyncInterval and logMinDelayReqInterval are reduced to improve accuracy and startup time.
Clock Grade 2 as defined in AES11 Digital Audio Reference Signal is signaled with clockClass.
Network equipment conforming to IEEE 1588-2008 uses default PTP profiles; for video streams, SMPTE 2059-2 PTP profile can be used.
In AVB/TSN networks, synchronization is achieved with IEEE 802.1AS profile for Time-Sensitive Applications.
The media clock is based on synchronized network time with an IEEE 1588 epoch. Clock rates are fixed at audio sampling frequencies of 44,1 kHz, 48 kHz and 96 kHz.
RTP transport works with a fixed time offset to network clock.

Transport

Media data is transported in IPv4 packets and attempts to avoid IP fragmentation.
Real-time Transport Protocol with RTP Profile for Audio and Video is used over UDP transport. RTP payload is limited to 1460 bytes, to prevent fragmentation with default Ethernet MTU of 1500 bytes.
Contributing source identifiers and TLS encryption are not supported.
Time synchronization, media stream delivery, and discovery protocols may use IP multicasting with IGMPv2 negotiation. Each media stream is assigned a unique multicast address ; only one device can send to this address.
To monitor keepalive status and allocate bandwidth, devices may use RTCP report interval, SIP session timers and OPTIONS ping, or ICMP Echo request.
AES67 uses DiffServ to set QoS traffic priorities in the Differentiated Services Code Point field of the IP packet. Three classes should be supported at a minimum:
Class nameTraffic typeDefault DiffServ class
ClockIEEE 1588-2008 time events *EF
MediaRTP / RTCP media streamsAF41
Best effortIEEE 1588-2008 signaling, discovery and connection managementDF

250 μs maximum delay may be required for time-critical applications to prevent drops of audio. To prioritize critical media streams in a large network, applications may use additional values in the Assured Forwarding class 4 with low-drop probability, typically implemented as a weighted round-robin queue. Clock traffic is assigned to the Expedited Forwarding class, which typically implements strict priority per-hop behavior. All other traffic is handled on a best effort basis with Default Forwarding.
RTP Clock Source Signalling procedure is used to specify PTP domain and grandmaster ID for each media stream.

Audio encoding

Sample formats include 16-bit and 24-bit Linear PCM with 48 kHz sampling frequency, and optional 24-bit 96 kHz and 16-bit 44.1 kHz. Other RTP audio video formats may be supported.
Multiple sample frequencies are optional. Devices may enforce a global sample frequency setting.
Media packets are scheduled according to 'packet time' - transmission duration of a standard Ethernet packet. Packet time is negotiated by the stream source for each streaming session. Short packet times provide low latency and high transmission rate, but introduce high overhead and require high-performance equipment and links. Long packet times increase latencies and require more buffering. A range from 125 μs to 4 ms is defined, though it is recommended that devices shall adapt to packet time changes and/or determine packet time by analyzing RTP timestamps.
Packet time determines RTP payload size according to a supported sample rate. 1 ms is required for all devices. Devices should support a minimum of 1 to 8 channels per stream.
Network latency is the time difference between the moment an audio stream enters the source, marked by RTP timestamp in the media packet, and the moment it leaves the destination. Latency depends on packet time, propagation and queuing delays, packet processing overhead, and buffering in the destination device; thus minimum latency is the shortest packet time and network forwarding time, which can be less than 1 μs on a point-to-point Gigabit Ethernet link with minimum packet size, but in real-world networks could be twice the packet time.
Small buffers decrease latency but may result in drops of audio when media data does not arrive on time. Unexpected changes to network conditions and jitter from packet encoding and processing may require longer buffering and therefore higher latency. Destinations are required to use a buffer of 3 times the packet time, though at least 20 times the packet time is recommended. Sources are required to maintain transmission with jitter of less than 17 packet times, though 1 packet time is recommended.

Interoperability with AVB

AES67 may transport media streams as IEEE 802.1BA AVB time-sensitive traffic Classes A and B on supported networks, with guaranteed latency of 2 ms and 50 ms respectively. Reservation of bandwidth with the Stream Reservation Protocol specifies the amount of traffic generated through a measurement interval of 125 μs and 250 μs respectively. Multicast IP addresses have to be used, though only with a single source, as AVB networks only support Ethernet multicast destination addressing in the range from 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff.
An SRP talker advertise message shall be mapped as follows:
StreamIDA 64-bit globally-unique ID.
Stream destination addressEthernet multicast destination address.
VLAN ID12-bit IEEE 802.1Q VLAN tag. Default VLAN identifier for AVB streams is 2.
MaxFrameSizeThe maximum size of the media stream packets, including the IP header but excluding Ethernet overhead.
MaxIntervalFramesMaximum number of frames a source may transmit in one measurement interval. Since allowed packet times are greater than AVB measurement intervals, this is always 1.
Data Frame Priority3 for Class A, 2 for Class B.
Rank1 for normal traffic, 0 for emergency traffic.

Under both IEEE 1588-2008 and IEEE 802.1AS, a PTP clock can be designated as an ordinary clock, boundary clock or transparent clock, though 802.1AS transparent clocks also have some boundary clock capabilities. A device may implement one or more of these capabilities.
OC may have as few as one port, while TC and BC must have two or more ports. BC and OC ports can work as a master or a slave. An IEEE 1588 profile is associated with each port. TC can belong to multiple clock domains and profiles.
These provisions make it possible to synchronize IEEE 802.1AS clocks to IEEE 1588-2008 clocks used by AES67.

Development history

The standard was developed by the Audio Engineering Society beginning at the end of 2010. The standard was initially published September 2013. A second printing including a patent statement from Audinate was published in March 2014. An update including clarifications and error corrections was issued in September 2015.
The Media Networking Alliance was formed in October 2014 to promote adoption of AES67.
In October 2014 a plugfest was held to test interoperability achieved with AES67. A second plugfest was conducted in November 2015 and third in February 2017.
In May 2016, the AES published a report describing synchronization interoperability between AES67 and SMPTE 2059-2.
In June 2016, AES67 audio transport enhanced by AVB/TSN clock synchronisation and bandwidth reservation was demonstrated at InfoComm 2016.
In September 2017, SMPTE published ST 2110, a standard for professional video over IP. uses AES67 as the transport for audio accompanying the video.
In December 2017 the Media Networking Alliance merged with the Alliance for IP Media Solutions combining efforts to promote standards-based network transport for audio and video.
In April 2018 AES67-2018 was published. The principal change in this revision is addition of a protocol implementation conformance statement.
The AES Standards Committee and AES67 editor, Kevin Gross, were recipients of a Technology & Engineering Emmy Award in 2020 for development of synchronized multi-channel uncompressed audio transport over IP networks.

Adoption

The standard has been implemented by Lawo, Axia, AMX, Wheatstone, , Riedel, , ALC NetworX, Audinate, Archwave, Digigram, Sonifex, Yamaha, QSC, Neutrik, Attero Tech, Merging Technologies, Gallery SIENNA, and is supported by RAVENNA-enabled devices under its AES67 Operational Profile.

Shipping products

Over time this table will grow to become a resource for integration and compatibility between devices. The discovery methods supported by each device are critical for integration since the AES67 specification does not stipulate how this should be done, but instead provides a variety of options or suggestions. Also, AES67 specifies Multicast or Unicast but many AES67 devices only support Multicast.
VendorProductDescriptionOS PlatformAES67 ModelSendReceiveMulticastUnicastNotes
Merging TechnologiesVirtual Audio DeviceRavenna/AES67 driversmacOS, Linux, WindowsRavenna AES67SAP, mDNS/RTSPSAP, mDNS/RTSPYYFree
ALC NetworksVirtual Sound CardRavenna/AES67 WDM driverWindowsRavenna AES67YFree
ALC NetworksRAV2SAPAES67 Discovery ToolsWindowsRavenna AES67SAPmDNS/RTSPYFree
SiennaAES67 to NDI GatewayAES67 to NDI GatewaymacOS, Linux, WindowsNative AES67SAPSAPYN
SiennaNDI to AES67NDI to AES67 SendermacOS, LinuxNative AES67SAPSAPYN
LawoVRX4Audio MixerWindowsRavenna AES67Y
HassebAoEAnalog and optical AES67 InterfaceNative AES67mDNS/RTSPmDNS/RTSPYY
QSCDSP, AmplifiersvariousQ-SYS AES67SAPSAPY
AXIAVariousvariousLivewire+ AES67YY
YamahaMixersvariousDante AES67SAPSAPYN
Attero TechEndpointsEndpointsAttero AES67SAPSAPYN
SoundTube EntertainmentVariousVariousDante AES67