Understanding AES67 and Its Role in Audio Networking

The Audio Engineering Society (AES) developed AES67 as an open standard for transporting high-quality audio over IP networks. Unlike proprietary protocols such as Dante or SoundGrid, AES67 is designed to bridge gaps between different manufacturers’ equipment, ensuring that a device from one brand can communicate with another from a different vendor. The standard defines a common set of transport protocols, synchronization methods, and media formats, but it does not lock users into a single codec or sampling rate. Instead, it provides a flexible framework that can accommodate a variety of audio codecs and formats, as long as they comply with the underlying real-time transport requirements.

AES67 builds on existing IETF standards, including Real-time Transport Protocol (RTP) for streaming, RTP Control Protocol (RTCP) for feedback, and IEEE 1588 Precision Time Protocol (PTP) for sample-accurate synchronization. This reliance on well-established protocols means that AES67 can be implemented on standard Ethernet hardware, reducing cost and complexity. The standard was first published in 2013 and has since been adopted by major broadcast, live sound, and installed sound systems. Its flexibility with codecs and formats is one of its key strengths, enabling system designers to choose the right balance between audio quality, latency, and bandwidth.

AES67 and Supported Audio Codecs

Although AES67 is often described as codec-agnostic, in practice it works best with uncompressed linear PCM and a few well-defined compressed formats. The standard specifies a mandatory set of parameters that all compliant devices must support, while leaving room for optional codecs. This approach ensures a baseline level of interoperability while allowing manufacturers to differentiate their products.

Linear PCM

Uncompressed pulse-code modulation (PCM) is the cornerstone of AES67 audio transport. It is supported by virtually all AES67 devices because it requires no additional encoding or decoding, keeping latency to a minimum. PCM can carry audio at various bit depths (typically 16, 24, or 32 bits) and sample rates (48 kHz is mandatory, 96 kHz is optional). The wide adoption of PCM makes it the safest choice for multi-vendor systems. Because the audio data is sent as raw samples inside RTP packets, no complicated transcoding is needed at the receiving end, preserving the original signal integrity.

JPEG 2000 (Audio Compression)

Some AES67 implementations, particularly those used in broadcast and high-end studio environments, support JPEG 2000 for lossy or lossless audio compression. JPEG 2000 is technically an image compression standard, but its wavelet-based algorithm also works well for audio when applied to spectral representations. In AES67, JPEG 2000 can reduce the bitrate of high-channel-count streams while maintaining very low latency (often below 1 ms). This codec is not part of the mandatory set, but it appears in products from manufacturers that prioritize bandwidth efficiency without sacrificing audio quality. It is especially common in systems that carry up to 128 channels over a 1 GbE link.

Opus and AAC-LC (Optional Codecs)

Several AES67 devices offer optional support for modern compressed codecs such as Opus and AAC-LC (Advanced Audio Codec Low Complexity). Opus is an open, royalty-free codec that excels at low-bitrate delivery, making it suitable for intercoms, remote contribution, and bandwidth-constrained links. AAC-LC, widely used in broadcasting, can also be encapsulated in RTP streams conforming to AES67. However, because these codecs introduce encoding latency, they are best suited for applications where a few additional milliseconds of delay are acceptable. System integrators must verify that both the sending and receiving devices support the same optional codec, as interoperability is not guaranteed for non-mandatory codecs.

RAVENNA and AES67-Specific Codecs

RAVENNA, a protocol closely related to AES67, often uses a proprietary packet structure but can run alongside AES67 streams on the same network. Some RAVENNA devices employ a lightweight differential PCM (DPCM) compression scheme to reduce bandwidth. While these codecs are not part of the AES67 specification, they can be transported using the same RTP framework, allowing them to interoperate with AES67 receivers that support the corresponding payload format. In practice, many RAVENNA/AES67 endpoints advertise their capabilities via Session Description Protocol (SDP) files, making it possible to negotiate codec usage automatically.

Audio Formats and Container Compatibility

The term "format" in the context of AES67 often refers to the file or container format of the original audio material. AES67 itself does not transport files; it streams real-time audio. Nevertheless, the standard can carry audio that originates from any container format as long as the codec inside is supported. For example, audio from a WAV file (which encapsulates linear PCM) can be streamed directly without conversion. Similarly, AIFF files with PCM data are fully compatible. Broadcast WAV (BWF) files, which include embedded metadata, can also be streamed, though the metadata may need to be extracted and sent separately via RTCP or other means.

Compressed file formats such as MP3, AAC in ADTS, or FLAC are not directly supported over AES67 because they require specific RTP payload types and timing models. However, system integrators can bridge these formats using a transcoding gateway. The gateway receives the compressed stream, decodes it to PCM, and then re-encodes it for AES67 transmission (or simply sends the PCM). This approach adds latency but allows legacy sources to be integrated into a modern AES67 network. Several manufacturers offer dedicated transcoding appliances that handle these conversions transparently.

Interoperability Across Manufacturers and Standards

AES67’s success hinges on its ability to ensure that devices from different vendors can discover each other, negotiate stream parameters, and deliver synchronized audio. The standard defines a common addressing scheme (based on RTP), a mandatory sampling rate (48 kHz), synchronization via PTPv2, and a common transport layer (UDP). However, interoperability extends beyond the core specification to include how devices handle optional codecs, how they manage multicast versus unicast, and how they report quality metrics.

The Audio Engineering Society maintains a list of AES67-compliant products, and many manufacturers participate in plugfests to test cross-vendor compatibility. For instance, devices from Yamaha, Neumann, DirectOut, and Genelec all support AES67 to varying degrees. When integrating these products, it is critical to check the codec and profile support in the device’s data sheet. Some devices only support the mandatory PCM at 48 kHz, while others offer additional rates and compressed codecs.

It is also important to consider the relationship between AES67 and SMPTE ST 2110-30, the standard for professional media over IP. ST 2110-30 is built upon AES67 and adds constraints to ensure deterministic behavior in broadcast environments. Any device that is compliant with ST 2110-30 will also be AES67-compatible, but the reverse is not always true. For high-stakes live production, ST 2110-30 certification may be required for reliable operation.

Practical Implementation and System Design

When designing an AES67 network that must handle multiple codecs and formats, the following areas require careful consideration:

Latency and Synchronization

Different codecs introduce different amounts of processing delay. Uncompressed PCM adds essentially zero latency beyond network transit, while codecs like Opus or AAC-LC can add 5–20 ms of encode/decode latency. The AES67 standard specifies a maximum allowed latency of 1 ms for the packet transport itself (excluding codec delay), but overall system latency is the sum of codec, network, and buffer delays. System designers must account for the highest-latency codec in the path when setting stream alignment and PTP sync.

Bandwidth Management

An uncompressed 48 kHz/24-bit stereo AES67 stream requires about 3 Mbps of network bandwidth for the payload, plus overhead for RTP, UDP, IP, and Ethernet. Compressed codecs reduce this significantly: Opus at 64 kbps per channel uses only a fraction of the bandwidth. For large installations with hundreds of channels, using compressed codecs where audio quality demands are lower (e.g., talkback or monitor feeds) can free up capacity for high-resolution main streams. Managed switches with QoS (Quality of Service) settings that prioritize RTP traffic (DSCP EF or CS5) are essential to prevent packet loss, which can cause audible artifacts across all codecs.

Clocking and PTP

AES67 relies on IEEE 1588 PTPv2 to maintain sample accuracy across all devices. The PTP domain must be stable, with all devices locked to the same grandmaster clock. When using different codecs, the clocking requirements remain the same: each RTP stream must have a timestamp reference based on PTP. If a device uses a variable bitrate codec, the packet timing can become irregular; the receiver must use jitter buffers to smooth out the delivery. Administrators should monitor PTP offset and jitter to ensure the network remains within the ±1 µs recommended tolerance.

Challenges in Multi-Codec AES67 Environments

While AES67 provides a robust foundation, mixing multiple codecs on the same network introduces several pitfalls:

  • Lack of automatic negotiation: AES67 does not include a built-in mechanism for two devices to automatically agree on a codec. The sending device must know the receiver's capabilities, often requiring manual configuration or an SDP exchange via a control protocol like NMOS or Dante Domain Manager.
  • Transcoding overhead: If a source uses a codec not supported by the destination, an external transcoder must be added. This introduces extra latency, potential quality loss, and another point of failure.
  • Profile mismatch: Even when both devices support the same codec, they may use different sampling rates, bit depths, or channel counts. The AES67 mandatory profile (48 kHz, 24-bit, 1–8 channels) is a safe fallback, but optional profiles may not be universally understood.
  • Vendor-specific extensions: Some manufacturers extend AES67 with proprietary codecs that are only compatible with their own equipment. These “flavors” can break interoperability unless the receiving end includes the same decoder.

To avoid these issues, it is recommended to create a codec compatibility matrix for the entire system before procurement. For greenfield projects, sticking to the mandatory PCM profile ensures the widest possible interoperability. For legacy integrations, a standardized gateway from a reputable vendor can bridge older codecs into the AES67 domain.

The Future of AES67: Codec Evolution and Open Standards

As network bandwidth becomes cheaper and more abundant, the need for compressed audio in professional settings may diminish, but codec flexibility remains valuable for remote production and cloud-based audio workflows. The AES67 working group continues to evaluate new codecs for inclusion in future revisions. Opus is a strong candidate for a future mandatory codec due to its open licensing and excellent latency/quality trade-off. Meanwhile, SMPTE ST 2110-30 is gaining traction in broadcast, further solidifying the PCM baseline.

Another trend is the convergence of AES67 with the Audio Video Bridging (AVB) and Time-Sensitive Networking (TSN) standards. AVB/TSN provides guaranteed latency and bandwidth reservation, which can make high-codec-count AES67 streams more predictable. Several chip manufacturers are integrating AES67 capability directly into Ethernet controllers, reducing the cost of adding multiple codec support.

Finally, control and discovery protocols such as NMOS (Networked Media Open Specifications) are becoming essential in large AES67 installations. NMOS allows devices to advertise their codec capabilities dynamically, enabling automatic stream configuration without manual SDP exchange. Combining AES67 with NMOS IS‑04 (Discovery) and IS‑05 (Connection Management) creates a truly plug-and-play environment that supports multiple codecs seamlessly.

Conclusion

AES67 offers a versatile, standards-based approach to audio networking that accommodates a variety of audio codecs and formats. By mandating linear PCM while allowing optional compressed codecs like Opus, AAC-LC, and JPEG 2000, the standard gives system integrators the flexibility to balance audio quality, latency, and bandwidth. The key to successful multi-codec deployment lies in careful planning, thorough verification of device capabilities, and adherence to the mandatory profile as a common baseline. External resources such as the AES Standards website and the ITU codec references provide additional guidance. As the industry moves toward more automated network management and higher bandwidth, AES67 will continue to evolve, ensuring that diverse audio formats can coexist in a single IP infrastructure.