Introduction

Modern audio production environments demand flexibility, scalability, and interoperability across a wide range of equipment from different manufacturers. Traditional analog or dedicated digital audio transports often fall short when integrating complex broadcast, live sound, or recording systems. Audio-over-IP (AoIP) technologies have emerged as the solution, enabling high-quality audio transmission over standard Ethernet networks. Among these, AES67 stands out as a critical open standard that ensures seamless compatibility between otherwise incompatible AoIP protocols. Implementing AES67 in your audio network allows devices from competing ecosystems — such as Dante, Ravenna, Q-LAN, and others — to exchange audio streams reliably and with low latency. This article provides a comprehensive guide to understanding AES67, planning its deployment, and following best practices to achieve a robust, future-proof audio network.

What Is AES67?

AES67 is an open standard published by the Audio Engineering Society in 2013. It defines a set of requirements for high-performance audio-over-IP networks, covering transport format, synchronization, latency, and network configuration. Unlike proprietary AoIP protocols, AES47 (the original digital audio interface standard for IP networks) AES67 provides a common baseline that any compliant device can use to send and receive audio flows. It operates over standard IP networks using Real-time Transport Protocol (RTP) for media delivery and IEEE 1588 Precision Time Protocol (PTP) for clock synchronization. AES67 supports up to 8 channels per stream at sampling rates of 48 kHz with up to 24 bits per sample, and it can scale for larger channel counts through multiple streams.

The standard does not define a specific control protocol, so discovery and connection management rely on existing systems like SAP (Session Announcement Protocol) or proprietary controllers. This openness is both a strength and a challenge: AES67 ensures that audio payloads can be decoded by any compliant device, but system integrators must still handle addressing and routing, often with the help of a management application. The result is a highly flexible environment where a Dante transmitter can feed an AES67 stream to a Ravenna receiver, or a Q-SYS processor can output AES67 to a Neumann microphone, without requiring proprietary gateways.

For more background, refer to the official AES standards page and the AES67 Wikipedia article.

Core Requirements for AES67 Implementation

Deploying AES67 successfully requires meeting several technical prerequisites across your network infrastructure, connected devices, and software tools. Below we break down each area.

Network Infrastructure

AES67 streams are multicast by default, so your network switches must support IGMP snooping (Internet Group Management Protocol) to manage multicast group membership efficiently. Without IGMP snooping, switches would flood all ports with multicast traffic, causing unnecessary bandwidth consumption and potential packet loss. Additionally, enabling Quality of Service (QoS) with strict priority for audio traffic is essential to prevent congestion from data packets causing jitter or drops. The network should be gigabit Ethernet or faster, and all switches should support IEEE 802.1p priority tagging. For larger networks, consider using a managed switch with VLAN capabilities to isolate audio traffic from other data.

Device Compatibility

Not all AoIP devices support AES67 out of the box. Some vendors offer AES67 as a firmware upgrade or require enabling it in the device configuration. Check the specifications of your mixers, amplifiers, converters, microphones, and signal processors. Common brands that offer AES67 support include Allen & Heath (dLive, SQ), Yamaha (CL/QL series with a Dante card), Neumann (MT 48 audio interface), Riedel (Artist intercom), and QSC (Q-SYS platform). When selecting new equipment, prioritize models that explicitly list AES67 compliance to minimize interoperability headaches.

For software, you may need a stream management tool like Audinate Dante Controller (which includes AES67 mode), Ravenna Virtual Soundcard, or Merging Technologies tools. These applications help you configure streams, set multicast addresses, and monitor connection status.

Software and Control

While AES67 leaves control undefined, most implementations use one of the common discovery protocols: SAP (Session Announcement Protocol) or RTSP (Real Time Streaming Protocol) for stream setup. Some ecosystems, like Dante, provide a dedicated software layer that translates Dante flows to AES67. Others require you to manually assign multicast IP addresses, port numbers, and payload types. Familiarity with these parameters is essential for troubleshooting. The AES67 specification defines a specific RTP payload type (96) and requires the use of the L16 or L24 coding for uncompressed audio. Make sure your devices support the same codecs and sample rates (typically 48 kHz, 24-bit).

Step-by-Step Implementation Guide

The following steps outline a practical workflow for adding AES67 support to an existing or new audio network.

1. Assess Your Network Infrastructure

Begin by auditing your network hardware. Verify that all switches support IGMP snooping and have it enabled. Check if your switch’s firmware is up to date. Configure VLANs to segregate audio traffic from general data traffic (e.g., file transfers, internet) to reduce latency and packet loss. Determine the available bandwidth: each AES67 stream at 48 kHz, 24-bit stereo uses about 6 Mbps. Plan for future expansion by leaving headroom of 30% or more. For large channel counts (e.g., 64×64), you may need 10 Gbps links for the backbone. Use a network analyzer tool or a switch with port mirroring to capture background traffic and ensure no rogue broadcasts interfere with synchronization.

2. Configure Multicast and QoS

Set up a dedicated multicast IP address range (e.g., 239.0.0.0/8). Assign each AES67 stream a unique multicast group. Enable IGMP snooping on all switches, and configure the querier election so that one switch acts as the multicast router. For QoS, classify audio packets with DiffServ Code Point (DSCP) values. AES67 specifies that audio RTP traffic should be marked as EF (Expedited Forwarding) with DSCP 46, and PTP event messages as DSCP 47 (CS5). Other network traffic should be lower priority. On managed switches, set up strict priority queues for these traffic classes.

3. Set Up Precision Time Protocol (PTP)

Synchronization is the cornerstone of any AoIP network. AES67 mandates the use of IEEE 1588-2008 (PTPv2) for clock distribution. Designate one grandmaster clock — usually the most stable source such as a GPS lock or a high-precision oscillator. Configure all other devices as slave clocks. The grandmaster can be a dedicated PTP appliance, a network switch with boundary clock capability, or a device like a Dante dS218. Ensure that PTP messages are not delayed by switch buffers; many managed switches offer a transparent clock mode to correct for residence time. Test synchronization by measuring offset between devices; it should remain under 1 microsecond for optimal audio alignment.

4. Stream Configuration and Routing

Using your chosen management software, create AES67 streams from source devices. Typically you specify:

  • Stream name (something descriptive)
  • Multicast address (unique on the network)
  • Port number (often default 5004)
  • Payload type (96 for AES67 L16 or L24)
  • Sample rate and bit depth (48 kHz, 24-bit)
  • Channel count (1 to 8 per stream)

On the receiving side, configure the device to subscribe to the same multicast group. Verify that the PTP reference clock is recognized. Use the management tool’s connection status indicators to confirm that packets are arriving without errors. Some systems also provide a latency measurement; aim for less than 1 ms end-to-end.

5. Test and Verify

After configuration, perform thorough testing. Send a known audio signal (e.g., 1 kHz tone or a test track) and measure the received audio on a scope or DAW. Check for dropouts, noise, or phase issues. Use network diagnostic tools like Wireshark to inspect RTP packets and verify sequence numbers and timestamps. Monitor the PTP offset continuously; any drift above 5 microseconds may indicate synchronization problems. Stress-test the network by adding multiple streams and recording the CPU load on switches. Finally, run the system for several hours under typical operating conditions to ensure stability.

Best Practices for Reliable Operation

Following a few best practices can significantly improve the reliability and ease of management of an AES67 network.

Network Segmentation and VLANs

Isolate AoIP traffic using VLANs to contain multicast streams and prevent interference from other services. Place all audio devices in a dedicated audio VLAN. Configure the switch’s IGMP snooping to operate on that VLAN only. This also improves security by limiting access to audio streams. If you must cross subnets, use a multicast router with PIM (Protocol Independent Multicast) — but note that AES67 is simplest when all devices reside on the same broadcast domain.

Firmware and Software Updates

Manufacturers regularly improve AES67 compatibility and fix bugs. Keep all network switches, audio devices, and management software updated. Enable automatic firmware update notifications where possible. Before updating, verify compatibility with existing configurations; some firmware updates may change default QoS or PTP settings.

Documentation and Training

Maintain a detailed network diagram showing switch ports, VLAN assignments, multicast groups, and PTP grandmaster location. Document the IP address plan and stream naming conventions. Train technical staff on AES67 basics, PTP configuration, and how to use diagnostic tools. Create a troubleshooting checklist for common issues like clock drift, stream loss, or audio distortion. Good documentation saves hours of downtime during events.

Common Challenges and Troubleshooting

Even with careful planning, challenges can arise. Here are typical problems and their solutions.

Clock Synchronization Issues

If devices report high PTP offset or audio artifacts, check that the PTP grandmaster is reachable via the network. Ensure switches are configured as transparent clocks or boundary clocks—ordinary switches that do not handle PTP can cause large delays. Also confirm that all devices are using the same PTP profile (AES67 profile: two-step, end-to-end, delay request-response). Adjust the network topology to keep PTP traffic on a dedicated VLAN or ensure it has the highest QoS priority.

Bandwidth and Latency

When streaming many channels simultaneously, network congestion can cause dropped packets. Monitor port utilization on your switches. If a port is near capacity, redistribute streams across multiple ports or upgrade to 10 Gbps links. For latency issues, reduce the packet time (e.g., from 1 ms to 0.125 ms) if your devices support it, but be aware that smaller packet times increase CPU load on endpoints. Some switches introduce latency by buffering multicast; use switches with cut-through switching mode for lower latency paths.

Stream Unavailable or Not Subscribable

If a receiver cannot see a stream, check that the source is sending to the correct multicast address and that IGMP snooping is active. Verify that the receiver’s firmware supports the same payload type and sample rate. In some cases, disabling simple network management protocol (SNMP) on the switch can resolve IGMP issues. Also, ensure that the multicast TTL (time-to-live) is high enough (usually 4 is sufficient) to pass through all switches.

Use Cases and Applications

AES67’s interoperability makes it valuable across many audio production environments.

Broadcast Studios

Radio and TV stations often mix equipment from multiple vendors: mixing consoles from Calrec or Lawo, intercom systems from Riedel, and audio over IP codecs from AJA or Tieline. AES67 allows each vendor’s gear to share audio without needing dedicated converters. For example, a Calrec console can output AES67 feeds directly to a Riedel intercom, while a remote codec receives program audio via AES67 from the master control. PTP synchronization ensures that all sources lock together for seamless transitions and lower-jitter broadcast feeds.

Live Sound

Touring systems and installed venues benefit from AES67 when integrating PA processors, stage boxes, and wireless microphone receivers. A Yamaha CL5 with a Dante card can output AES67 to a QSC Q-SYS system, which processes the audio for zone distribution. Similarly, a Neumann MT 48 interface can receive AES67 from a digital console to record multitrack. AES67 reduces the need for proprietary stage racks and simplifies the cabling between FOH, monitors, and broadcast trucks.

Recording Studios

In production environments, studios often have a patchwork of audio interfaces. AES67 allows a Pro Tools HDX system to receive tracks from a Merging Horus via Ravenna (AES67 mode) while sending monitor mixes to a Focusrite RedNet. This enables large multi-room facilities to route audio without repatching. The low latency (typically under 1 ms) is acceptable for tracking and even for live monitoring when proper synchronization is maintained.

The Future of AES67 and AoIP

AES67 remains relevant as the industry moves toward higher-resolution audio and more flexible networking. The AES67 specification is the foundation for newer standards like ST 2110-30 (professional media over IP), which expands the format to support more channels and higher sample rates (e.g., 96 kHz, 32-bit). Many broadcast and production facilities are adopting ST 2110, which incorporates AES67 as its audio layer. As such, investing in AES67 compatibility now ensures that your network can later upgrade to full ST 2110 with minimal reconfiguration. Additionally, the AES67 standard is now part of the AVB (Audio Video Bridging) ecosystem, and many newer devices support both AES67 and IEEE 1722 (AVTP) for tighter integration with video and control networks.

Vendors continue to simplify AES67 setup by offering automatic discovery and dynamic stream negotiation. Tools like Audinate’s AES67 Mode in Dante Controller make it easy to switch between Dante and AES67 streams. The open nature of AES67 also encourages innovation in remote production, cloud-based processing, and distributed mixing. As network speeds increase and latency decreases, AES67 will remain a backbone technology for professional audio.

Conclusion

Implementing AES67 in your audio network is a forward-looking decision that unlocks the full potential of audio-over-IP. By following the steps outlined — from assessing infrastructure and configuring PTP to thorough testing and ongoing maintenance — you can build a system that connects devices from different manufacturers with low latency and high reliability. AES67 removes the barriers of proprietary protocols, allowing you to mix and match the best tools for your workflow. Whether you are equipping a broadcast control room, deploying a live sound rig, or upgrading a recording studio, AES67 provides a proven, open standard that ensures seamless compatibility and prepares your network for the next generation of professional audio.