The Evolution of Audio Networking: Why AES67 Matters

Audio over IP (AoIP) has become the backbone of modern audio production, broadcast, and installation. As studios, live sound venues, and corporate AV systems transition from analog and digital point-to-point connections to converged Ethernet networks, the need for a common language between different manufacturers' equipment has grown critical. AES67, an open standard from the Audio Engineering Society, fills that gap. It defines a set of interoperability guidelines that allow any compliant device to send and receive high-quality, low-latency audio over standard IP networks, regardless of its proprietary protocol.

Before AES67, broadcasters and integrators often had to choose a single ecosystem—such as Dante, Livewire, Ravenna, or Q-LAN—and stick with it to ensure compatibility. This created vendor lock-in and limited flexibility. AES67 changed the landscape by specifying a common transport stream, clocking mechanism, and discovery scheme. It does not replace those native protocols but instead provides a bridge, enabling them to coexist and exchange audio seamlessly. This article explores what AES67 is, how it works, how to implement it in real-world networks, and what benefits and challenges you can expect.

What Is AES67? The Technical Framework

AES67, formally published as AES67-2015 and updated in 2018, is a standard for high-performance Audio over IP interoperability. It defines a profile for transporting uncompressed digital audio in real time over IP networks using existing standards wherever possible. The core components include:

  • Transport Layer: Audio is packetized using Real-Time Transport Protocol (RTP) over UDP/IP. The standard mandates payload formats for PCM audio, typically 16 or 24 bits per sample, with sample rates of 48 kHz or 96 kHz. Channels are mapped into a stream using an RTP payload format based on AES-3 or ST 2022-6 choices.
  • Clocking and Synchronization: AES67 relies on IEEE 1588-2008 Precision Time Protocol (PTP) to achieve sample-accurate synchronization across all devices. It specifies a default PTP profile (draft version of SMPTE ST 2059-1) that ensures all devices lock to a common clock with sub-microsecond accuracy, enabling seamless phase alignment and minimal jitter.
  • Device Discovery and Connection Management: The standard uses a simple multicast-based session discovery protocol (SDP) based on RTSP and SAP. Devices announce available streams and can be discovered manually or via software controllers. Unlike proprietary systems, AES67 does not require a central management server; discovery is inherent in the IP multicast infrastructure.

This combination of open, industry-standard protocols means AES67 is both network-agnostic and relatively straightforward to implement on existing Ethernet infrastructure, as long as the network can handle multicast traffic and PTP timing.

How AES67 Differs from Other AoIP Protocols

Dante, Ravenna, and Livewire each have their own discovery, clocking, and transport mechanisms. AES67 acts as a lowest-common-denominator “universal translator.” For example, a Dante device can be configured to output an AES67 stream, which a Livewire device can receive and convert into its native format. This requires that the manufacturer implements an AES67 mode, but many now do. AES67 itself is not a full-featured network management system; it does not specify how to route or control streams beyond basic connection. For complex routing, you still need the native software—but AES67 ensures that when a path is established, the audio will flow correctly.

Key Features of AES67

  • True Interoperability: Any two AES67-compliant devices can exchange audio directly. This includes mixers, stage boxes, audio interfaces, codecs, and even some cameras with AIP capability.
  • Low Latency: AES67 supports latency as low as 1 millisecond (using 1-ms packet time) and commonly operates at ¼ ms, ½ ms, 1 ms, or 2 ms depending on network strength. This makes it suitable for live sound foldback, in-ear monitors, and broadcast talkback.
  • Precision Synchronization: Using IEEE 1588 PTP with the AES67 profile, all devices stay locked within 1 μs of each other. This allows multiple streams to be summed, switched, or processed without phase cancellation.
  • Scalability: Because AES67 uses IP multicast, one stream can be shared with many receivers. Networks can grow from a few dozen channels to thousands without fundamental changes—as long as the network is properly designed for multicast.
  • Media Clock Mapping: AES67 can carry signals with sample rates from 44.1 kHz up to 192 kHz (though 48 and 96 kHz are most common) and bit depths up to 24. It can also transport AES3 data directly.
  • Redundancy: While not part of the core spec, AES67 streams can be duplicated over separate IP paths using standard network redundancy (e.g., ST 2022-7) when implemented by the device.

Implementing AES67: A Practical Guide

Successfully deploying AES67 in a production environment requires careful planning. The following steps outline the key considerations, from device selection to network configuration and ongoing monitoring.

1. Select Compatible Devices

Many professional audio manufacturers now support AES67 as a native or optional mode. Look for products that clearly state AES67 compliance in their datasheets. Common examples include:

  • Mixing consoles: Allen & Heath dLive, Yamaha CL/QL series, Behringer Wing (via expansion card)
  • I/O stages: RME Digiface, Focusrite RedNet, Dante products with AES67 firmware
  • Network bridges: Audinate Dante interface with AES67 mode, Merging Technologies Anubis (Ravenna)
  • Broadcast codecs: Tieline, Comrex, APT codecs often include AES67 support

When mixing different brand stacks, verify that the AES67 implementation includes the same PTP profile and packet time settings. Some manufacturers may have custom PTP profiles that differ from the AES67 default; these can be adjusted in device settings if allowed.

2. Network Infrastructure Preparation

AES67 works best on a deterministic, low-jitter Ethernet network. Key network requirements:

  • Managed Gigabit Switches: Use switches that support IGMP snooping, PTP transparent clock or boundary clock functionality, and Quality of Service (QoS) prioritization. Consumer-grade switches often drop multicast or add excessive latency.
  • Multicast Handling: AES67 streams are multicast group addresses (in the 239.x.x.x range per default). IGMP snooping ensures that only ports subscribed to a stream receive its packets, reducing unnecessary traffic. Enable the feature on all switches.
  • VLANs (Optional): Place audio devices on a dedicated Audio VLAN to isolate them from data traffic. This helps control broadcast storms and QoS policies. Ensure the PTP clock domain is either bridged across VLANs or use a PTP-aware switch that can deliver time across subnets.
  • Network Topology: Avoid daisy-chaining more than three switches; use a star or spine-leaf topology for low hop count. Each switch hop adds a small amount of delay and jitter, though modern managed switches can keep this very low.
  • Bandwidth: A single 48 kHz, 8-channel AES67 stream with 16-bit samples uses about 8 Mbps. For large systems, ensure the network backbone has enough bandwidth and that multicast pruning is properly configured.

3. Configure Quality of Service (QoS)

Audio packets must be prioritized over data traffic to guarantee consistent arrival times. Implement the following QoS policies on all switches and endpoints:

  • DSCP (Differentiated Services Code Point): Mark AES67 audio RTP packets with DSCP 46 (Expedited Forwarding) or 34 (Assured Forwarding). For PTP event messages, use DSCP 56 (Network Control).
  • IEEE 802.1p: Set 802.1p priority to 5 for audio and 7 for PTP. Many switches map these to hardware queues.
  • Trust Boundaries: Ensure switches trust the priority markings from the audio endpoints. If endpoints do not mark correctly, enable marking at the switch ingress based on UDP port ranges (default AES67 RTP ports are 5004, 5005, and port 319 for PTP events).

4. Clocking and PTP Setup

Synchronization is perhaps the most critical aspect of AES67. The standard requires a PTP grandmaster clock that all other devices follow. Steps:

  • Select a Grandmaster: Use a dedicated PTP grandmaster device (e.g., a GPS-referenced clock from Meinberg, Seiko, or an audio router with PTP master capability). Many audio interfaces can act as masters, but a dedicated grandmaster is best for large networks.
  • PTP Profile: Set all devices to the AES67 PTP profile (also known as SMPTE ST 2059-1 profile). This uses a sync interval of 125 ms (8 packets per second) and delay request interval of 1 second. Some devices support a more aggressive profile for lower lock times; ensure matching across all devices.
  • Boundary and Transparent Clocks: For larger networks, enable PTP boundary clock feature on switches. This recovers timing and re-transmits it, removing cumulative jitter. Transparent clocks adjust PTP timestamps for switch residency time—also a good option if boundary clocks are not available.
  • Verification: After initial setup, verify synchronization using PTP monitoring tools (e.g., PTPd, ptp4l, or manufacturer’s software). The offset from master should be less than 500 ns for reliable operation.

5. Stream Configuration and Testing

Once the network is ready, configure AES67 streams:

  • Enable AES67 mode on each source device. This typically involves selecting a “Redundancy” or “Protocol” setting.
  • Define stream parameters: sampling rate (usually 48 kHz), bit depth (16 or 24 bits), packet time (1 ms is a safe starting point), and multicast IP address (leave on auto or assign within the 239.255.x.x range).
  • On the receiver side, discover the available streams. Some devices automatically list AES67 streams that match their parameters; others require manual IP entry.
  • Conduct a latency and jitter test. Use a reference test signal (e.g., a 1 kHz tone) and measure delay with a scope or analyzer. Acceptable total network latency should be under 2 ms for most live sound applications.

Benefits of AES67 Adoption

  • Elimination of Vendor Lock-In: You can mix and match equipment from different brands without worrying about protocol incompatibility. This creates cost savings and future flexibility.
  • Network Convergence: AES67 runs on standard Ethernet, allowing audio to coexist with control video and data on the same infrastructure, provided VLANs and QoS are properly set.
  • Future-Proofing: As the media industry moves toward IP-based production (SMPTE ST 2110), AES67 serves as the audio component in many ST 2110 implementations. Investing in AES67 today positions you for tomorrow’s standards.
  • Reduced Latency: With proper configuration, AES67 can deliver sub-2-ms latency end-to-end, rivaling direct analog connections.
  • Scalability and Flexibility: Adding new devices requires only a network connection and configuration, not new cabling or signal distribution hardware.

Challenges and Considerations

While AES67 is powerful, it is not without challenges. Understanding these will help you avoid pitfalls:

  • Learning Curve: Network engineers unfamiliar with PTP or multicast may struggle. Invest in training or hire a specialist for initial setup.
  • Limited Functionality: AES67 is a transport and sync standard; it does not provide automatic routing, redundancy management, or control. Native protocols (e.g., Dante Controller) offer richer management features.
  • Device Compatibility Gaps: Not all “AES67-compatible” devices work flawlessly together. Differences in PTP profiles, packet time defaults (e.g., 125 μs vs 1 ms), or SDP announcement intervals can require manual tweaking.
  • Network Requirements: The need for managed switches, PTP support, and QoS can increase infrastructure cost. However, in most professional environments, these features are already present.
  • Multicast Saturation: Without proper IGMP snooping and pruning, AES67 streams can flood the network. Ensure all switches support and have enabled these features.

Use Cases: Where AES67 Shines

Broadcast Radio and Television

In broadcast facilities, AES67 allows the integration of codecs with digital consoles, routing audio between studios and transmission centers. Many broadcast codecs (Tieline, Comrex) support AES67, enabling seamless call-in audio and remote contribution. The low latency is crucial for live on-air communication.

Live Sound Reinforcement

Festival and touring setups often involve mixing consoles from different manufacturers. AES67 provides a universal bridge between stages, monitors, and broadcast trucks. For example, a FOH console (e.g., Yamaha CL5) can send a multichannel mix over AES67 to a monitor console (e.g., Allen & Heath dLive) without needing a dedicated digital snake.

Installed Audio (Corporate AV and Education)

Large conference centers, performing arts venues, and universities use AES67 to connect microphones, DSP units, and amplifier endpoints from various vendors. The ability to run audio over existing IT infrastructure simplifies installation and future changes. PTP synchronization ensures that distributed audio playback remains in phase.

AES67 is not the final stop. It is now a building block for more comprehensive standards like SMPTE ST 2110, which separates video, audio, and metadata over IP for professional broadcast. ST 2110 embeds AES67 for its audio component (ST 2110-30 and ST 2110-31). The synergy means that AES67 devices can be used directly in ST 2110 environments. Also, the Audio Engineering Society continues to update AES67 to address new requirements like higher sample rates and improved discovery.

Another emerging standard is Ravenna, which is fully AES67-compatible and adds advanced features like dynamic routing and self-healing. Many manufacturers now offer both pure AES67 and Ravenna modes. As the AoIP ecosystem matures, we can expect all professional audio devices to speak AES67 at their core, with optional proprietary extensions for power users.

Conclusion: A Foundation for Interoperable Audio Networking

AES67 is more than a technical specification; it is the key that unlocks interoperability in the AoIP world. By adopting a common set of transport, clock, and discovery mechanisms, it allows audio professionals to build flexible, scalable, and future-proof networks without being locked into a single vendor. Successful implementation requires careful attention to network infrastructure, PTP configuration, and device compatibility, but the payoff is significant: high-quality, low-latency audio that flows freely between any compliant device.

Whether you are designing a broadcast infrastructure, deploying a live sound system, or installing an enterprise AV network, AES67 provides the foundation for seamless audio integration. Start by auditing your current equipment for AES67 support, plan your network topology with multicast and PTP in mind, and test thoroughly before going live. With the right approach, AES67 can transform your audio over IP ecosystem into a truly interoperable, production-ready asset.