Understanding AES67 and Its Benefits

AES67 is a standard developed by the Audio Engineering Society that defines a method for transporting high-quality audio over IP networks. It was created to solve a fundamental problem in professional audio: the proliferation of incompatible audio-over-IP protocols. Before AES67, devices using Dante, Ravenna, Livewire, or Q-LAN could not easily communicate with each other, forcing studios and broadcast facilities into vendor-specific ecosystems. AES67 provides a common language that these systems can speak, enabling interoperability without replacing existing infrastructure.

The standard specifies audio transport using RTP (Real-time Transport Protocol) over UDP/IP networks, with PCM audio formats at sampling rates of 48 kHz or 96 kHz and bit depths of 16, 20, or 24 bits. It supports unicast and multicast transmission, allowing flexible routing in both small studios and large-scale broadcast facilities. The key benefits of AES67 include:

  • Standardized audio streaming that works across different manufacturer ecosystems
  • Reduced setup complexity by eliminating the need for proprietary bridging hardware
  • Increased flexibility in routing audio between consoles, mixing desks, and other devices
  • Scalability for large audio environments with dozens or hundreds of channels
  • Cost savings by leveraging existing IP network infrastructure instead of dedicated audio cabling

For facilities that already have a mix of legacy analog consoles, digital mixing desks, and newer AoIP-equipped devices, AES67 offers a practical path to unification. It does not require replacing all equipment at once; instead, it allows incremental integration, preserving capital investments while enabling modern workflows.

The Core Technical Specifications

AES67 operates with specific performance parameters to ensure professional-grade audio quality. The standard mandates support for a minimum of eight channels per stream, with sample rates of 48 kHz and 96 kHz. It uses the L24 audio coding format, which is 24-bit linear PCM, and requires network latency of no more than 1 millisecond for unicast flows and 2 milliseconds for multicast flows. These figures make AES67 suitable for live sound reinforcement, broadcast, and recording applications where low latency is critical.

Packetization follows the RTP standard, with each packet carrying a fixed number of audio samples. The default packet time is 1 millisecond, which at 48 kHz sample rate means 48 samples per packet. This approach ensures that audio data is delivered with deterministic timing, which is essential for synchronization across multiple channels and devices. The standard also incorporates PTPv2 (Precision Time Protocol) for clock synchronization, enabling sample-accurate alignment between devices on the network.

Interoperability Between Protocols

The primary value of AES67 lies in its ability to bridge different audio-over-IP protocols. Dante, developed by Audinate, is one of the most widely used AoIP systems in live sound and installed audio. Ravenna, developed by ALC NetworX, is common in broadcast and production environments. Livewire, from The Telos Alliance, is popular in radio broadcasting. AES67 allows these systems to exchange audio streams without custom gateways or format conversion.

For example, a Dante-enabled mixing console can send audio to a Ravenna-based broadcast processor using AES67 as the transport layer. Similarly, a Livewire system can receive AES67 streams from a Dante network, allowing radio stations to integrate digital mixing desks with their existing AoIP infrastructure. This interoperability is achieved through a common compliance profile that defines the specific RTP payload format, clock synchronization, and session description protocol (SDP) parameters.

Major manufacturers now include AES67 support in their products. Audinate's Dante firmware includes AES67 mode, Yamaha's consoles support AES67 via their TwinLANe interface, and Lawo's broadcast mixing desks use Ravenna, which is natively AES67-compatible. This broad adoption means that integration is often a matter of configuration rather than hardware addition.

Assessing Your Existing Equipment

Before beginning an AES67 integration project, conduct a thorough audit of your existing audio infrastructure. Document every console, mixing desk, processor, router, and peripheral device in your signal chain. For each device, determine whether it supports AES67 natively, supports a compatible protocol that can be configured for AES67, or requires external interfacing.

This assessment should include both hardware and software capabilities. Many modern digital mixing consoles include Ethernet ports that can be used for audio transport, but the exact implementation varies by manufacturer and model. Some consoles require optional interface cards or firmware upgrades to enable AES67 functionality. Others may support AES67 only in specific operating modes or with software licenses.

Checking Native Support

Devices with native AES67 support will have a network port that can be configured to send and receive AES67 streams directly. Common examples include Allen & Heath dLive and Avantis consoles (with the appropriate Dante or SLink cards), Behringer Wing (with the Dante expansion card), and many broadcast consoles from Lawo and Calrec. For these devices, integration involves network configuration and stream routing rather than hardware conversion.

If your console supports Dante but not AES67 natively, check whether Dante firmware includes AES67 mode. Audinate's Dante cards and modules have supported AES67 since firmware version 4.0. Enabling this mode typically requires a settings change in the Dante Controller software. Similarly, Ravenna devices are inherently AES67-compatible because Ravenna uses the same RTP and PTP standards. Livewire+ systems from Telos can also be configured for AES67 operation with appropriate software updates.

Firmware and Software Considerations

Outdated firmware is a common obstacle to AES67 integration. Manufacturers regularly release updates that add AES67 support, improve stability, or expand compatibility. Before proceeding with physical installation, check the support pages for each device and apply the latest firmware versions. This is particularly important for network switches, which may require firmware updates to support the multicast traffic patterns used by AES67.

Control software also plays a role. For example, Dante Controller must be updated to a version that supports AES67 mode. Similarly, Ravenna's management software, such as Lawo's Ember+, must be configured to expose AES67 streams. Document all software versions and ensure they are compatible with each other before attempting integration.

Network Infrastructure Requirements

AES67 runs on standard Ethernet networks, but not all network switches are suitable. The standard requires support for IGMP snooping, which manages multicast traffic efficiently by sending streams only to ports that have requested them. Without IGMP snooping, multicast traffic floods all ports, consuming bandwidth and causing congestion. Managed switches from vendors such as Cisco, Netgear, HP, and Ubiquiti typically support this feature.

Quality of Service (QoS) is another critical requirement. AES67 audio streams must be prioritized over other network traffic to prevent packet loss and jitter. Configure QoS to assign the highest priority to audio traffic, typically using DiffServ Code Points (DSCP) with the EF (Expedited Forwarding) class. This ensures that even when the network is busy, audio packets are delivered with consistent timing.

Network capacity is also important. A single AES67 stream at 48 kHz with 24-bit resolution and eight channels requires approximately 6.2 Mbps of bandwidth. A facility with 48 channels of audio will need about 37 Mbps for audio alone, plus overhead for control traffic and other services. Gigabit Ethernet (1000BASE-T) is the minimum recommended for any AES67 deployment, with 10 GbE recommended for larger installations.

Upgrading or Adding AES67 Compatibility

For equipment that does not support AES67 natively, several upgrade paths are available. The choice depends on the specific devices involved, the number of channels needed, and the budget available. In many cases, a combination of approaches yields the best results.

Interface Devices and Converters

External interface boxes that convert analog or digital audio to AES67 streams are the most straightforward solution for legacy equipment. These devices accept line-level analog signals, AES3 digital audio, or ADAT optical inputs and output AES67-compatible RTP streams over Ethernet. Examples include the Focusrite RedNet series, the RME AVB-Tool series (with AES67 support), and the Ferrofish A32 Dante (with AES67 mode).

For analog consoles, a 16-channel interface box provides a simple way to add AES67 capability. Connect the console's line outputs to the interface's analog inputs using balanced XLR or TRS cables, then configure the interface to stream the audio as AES67 multicast streams. The same approach works in reverse for monitoring or playback: the interface receives AES67 streams and outputs analog signals to the console's line inputs.

Digital consoles with AES3 outputs can use a format converter to bridge to AES67. Devices such as the RME HDSPe AES or the Lynx AES16e can be configured to send AES3 data over IP using AES67 formatting. This approach preserves the digital nature of the signal, avoiding the conversion losses that occur with analog interfacing.

Bridging Protocols

Some facilities have a mix of AoIP systems that cannot directly exchange AES67 streams. In these cases, a protocol bridge device provides translation between systems. For example, a bridge that converts Dante to AES67 and vice versa allows a Dante console to communicate with an AES67-only processor. Second-generation Dante devices support AES67 natively, but older Dante devices may require a bridge.

The AES67 standard itself serves as the bridge. In practice, many manufacturers implement AES67 as a mode within their existing protocol. For example, a Yamaha CL5 console with a Dante card can be switched to AES67 mode, allowing it to communicate with Ravenna devices directly. Similarly, a Wheatstone console using Livewire+ can be configured to send AES67 streams to a Dante network.

Firmware Upgrades

Firmware upgrades are the least expensive path to AES67 compatibility. If your existing equipment includes network ports that are used for control or audio transport, check whether the manufacturer has released firmware that adds AES67 support. This is common for consoles and audio processors that were originally released with proprietary protocols but have been updated to support AES67 through software.

For example, early firmware versions of the Allen & Heath dLive series did not support AES67, but later versions added support through the SLink expansion port. Similarly, some models of the Yamaha Rivage PM series received AES67 support through firmware updates. Always verify with the manufacturer that the updated firmware is stable and supported in your configuration.

Configuring Your Network for Seamless Operation

Network configuration is the most technically demanding aspect of AES67 integration. A properly configured network ensures low latency, jitter-free audio, and reliable stream discovery. The following guidelines cover the essential steps for building a robust AES67 network.

Quality of Service (QoS) Prioritization

QoS is non-negotiable for AES67 networks. Without QoS, audio packets compete with data traffic on an equal basis, leading to packet loss, jitter, and audible artifacts. Configure your managed switches to classify and prioritize AES67 traffic based on DSCP values. The AES67 standard recommends using DSCP EF (46) for audio data, which provides expedited forwarding with low latency and low loss.

Set up QoS policies on every switch in the audio path. The policies should include:

  • Classification of incoming packets based on DSCP values
  • Assignment of the highest priority queue for audio traffic
  • Strict priority queuing rather than weighted fair queuing for audio traffic
  • Bandwidth reservation for audio streams to prevent starvation of other services

Test your QoS configuration by generating traffic on the network and verifying that audio streams maintain consistent latency. Network analysis tools such as Wireshark can capture audio packets and display timing information, helping you confirm that QoS is working correctly.

Network Segmentation and Subnetting

Place all AES67 devices on the same subnet for optimal performance. When devices are on different subnets, multicast traffic must pass through a router, which can introduce latency and packet loss. If your facility requires multiple subnets, configure multicast routing with IGMP proxy or PIM (Protocol Independent Multicast) to ensure audio streams reach all destinations.

VLAN segmentation can be useful for security and traffic management. Create a dedicated audio VLAN that carries only AES67 and control traffic. This isolates audio from data traffic such as web browsing, email, and file transfers, reducing the risk of interference. Assign the audio VLAN a high priority in the switch configuration to further protect stream integrity.

Use static IP addresses for all AES67 devices whenever possible. Static addressing eliminates the dependency on DHCP servers, which can introduce delays if they fail or restart. If DHCP is required, configure address reservations to ensure that each device always receives the same IP address. This consistency simplifies stream configuration and troubleshooting.

Latency and Synchronization

AES67 uses PTPv2 (IEEE 1588-2008) for clock synchronization. A PTP grandmaster clock provides a reference time that all devices on the network use to align their audio clocks. Without accurate PTP synchronization, audio streams drift relative to each other, causing clicks, pops, and sample slippage.

Select a PTP grandmaster that is accurate and stable. GPS-disciplined oscillators provide the highest accuracy, but for most facilities, a dedicated PTP switch or a software grandmaster running on a stable server is sufficient. Configure all switches to support PTP transparent clock mode, which compensates for the delay that packets accumulate as they pass through the switch.

Set the PTP domain correctly. AES67 uses PTP domain 0 by default. Ensure that all devices are configured to the same domain number so they synchronize to the same grandmaster. If your facility also uses Dante, note that Dante uses PTP domain 0 as well, which is compatible with AES67 synchronization.

Implementing AES67 in Your Workflow

With hardware and network prepared, the implementation phase focuses on configuring devices, setting up streams, and validating performance. Follow a systematic approach to minimize disruption and ensure a smooth transition.

Device Configuration

Configure each AES67 device with its network settings, including IP address, subnet mask, gateway, and DNS if needed. Enable AES67 mode on each device, which may involve changing a setting in the device's control panel or software. For Dante devices, this means enabling AES67 mode in Dante Controller. For Ravenna devices, it means configuring the audio networking mode to AES67.

Define the audio streams that each device will send and receive. For sending, configure the stream with the desired sampling rate (48 kHz is the most common), bit depth (24 bits recommended), number of channels, and multicast or unicast addressing. For receiving, subscribe each device to the streams it needs. Most control software allows drag-and-drop routing between sources and destinations.

Document every stream with its multicast IP address, port number, and channel mapping. This documentation is invaluable for troubleshooting and for future expansion. Use a consistent naming convention for streams that includes the source device, destination zone, and channel range (e.g., "FOH-Console_Stage-1_Ch1-8").

Routing and Stream Management

Stream routing in AES67 is managed through SDP (Session Description Protocol) files, which describe the format and addressing of each stream. Some systems automatically generate and exchange SDP files through discovery protocols such as mDNS (Bonjour) or SAP (Session Announcement Protocol). Others require manual SDP file import or entry.

For large installations, consider using a centralized stream management system. Products like Dante Domain Manager or Lawo's Ember+ provide a unified interface for routing audio between devices from different manufacturers. These systems handle SDP exchange, PTP monitoring, and stream status, simplifying day-to-day management.

Test routing by sending a test tone from a source device and verifying that the destination device receives it. Check both the level and the phase of the audio to ensure that all channels are correctly mapped. If you are using multicast streams, verify that only the intended devices are subscribed to each stream by checking IGMP group membership on the switches.

Testing and Validation

Comprehensive testing is essential before relying on AES67 in live production. Start with a single stream pair and progressively add more streams until the full channel count is reached. Monitor network utilization, CPU load on switches, and PTP synchronization stability throughout the testing process.

Measure end-to-end latency from analog input to analog output. Use a pulse generator and oscilloscope or a dedicated latency measurement tool to confirm that latency falls within acceptable limits. For live sound applications, latency should be below 2 milliseconds round trip. For broadcast, higher latency can be tolerated, but consistency is critical.

Test failover behavior. If your network supports redundant paths (e.g., via Spanning Tree Protocol or link aggregation), simulate a cable failure and verify that audio continues without interruption. Some AES67 devices support stream redundancy through redundant network interfaces; confirm that this works correctly in your setup.

Train staff on managing the AES67 system. Provide documentation on stream routing, PTP monitoring, and common troubleshooting steps. Designate a point person who is responsible for maintaining the network and managing firmware updates. AES67 networks require ongoing attention, so building internal expertise is a worthwhile investment.

Troubleshooting Common Integration Challenges

Even with careful planning, integration projects often encounter issues. The following sections describe common problems and their solutions.

Latency and Jitter Issues

Excessive latency or jitter is the most common complaint in AES67 deployments. Latency problems usually stem from network congestion or inadequate QoS configuration. Check that QoS policies are applied correctly on all switches and that audio traffic is being placed in the highest priority queue. Use switch monitoring tools to verify that no packets are being dropped or delayed.

Jitter, which causes audio distortion or dropouts, often results from clock synchronization problems. Verify that all devices are synchronized to the same PTP grandmaster and that the grandmaster is functioning correctly. Use a PTP monitoring tool such as ptp4l or the built-in diagnostics in your control software to check offset and delay values. If the grandmaster is unstable, consider upgrading to a dedicated PTP switch or GPS-disciplined clock.

Device Discovery and Compatibility

If devices cannot discover each other on the network, check that they are on the same subnet and VLAN. Multicast traffic for discovery (mDNS) and stream announcement (SAP) may not cross router boundaries without configuration. If devices must reside on different subnets, configure multicast forwarding or use static SDP file exchange.

Compatibility issues can arise even among devices that claim AES67 support. Different manufacturers may implement certain optional features differently, leading to partial interoperability. Check the compliance documentation for each device and ensure that they all support the same AES67 profile. The AES67 standard includes several profiles that specify different levels of support; choosing devices that match on the same profile eliminates most compatibility problems.

Future-Proofing Your Audio Infrastructure with AES67

AES67 is not the final word in audio-over-IP, but it provides a strong foundation for future growth. As broadcast and production facilities move toward IP-based infrastructure, the ability to integrate diverse equipment becomes increasingly valuable. AES67 is also the audio component of the SMPTE ST 2110 standard for professional media over managed IP networks, which is becoming the default for television production and distribution.

Scalability and Expansion

Design your network with expansion in mind. Choose switches with sufficient port density and bandwidth to accommodate future devices. Plan for at least 20% headroom in bandwidth utilization. Select equipment that supports firmware upgrades, as future revisions of the AES67 standard may include new features or performance improvements.

Consider adopting a single protocol across your entire facility where possible. While AES67 provides interoperability, using a unified protocol such as Dante or Ravenna throughout simplifies management and troubleshooting. AES67 serves as the fallback for bridging systems that use different protocols.

Emerging Standards and SMPTE ST 2110

SMPTE ST 2110 is a suite of standards for transport of video, audio, and metadata over IP networks. Its audio component, ST 2110-30, is based on AES67. Facilities that adopt SMPTE ST 2110 for video will naturally support AES67 for audio, creating a seamless IP infrastructure for all media types. Planning for ST 2110 today ensures that your audio network remains relevant as production technology evolves.

For broadcasters and production houses, moving toward ST 2110 unlocks advanced capabilities such as seamless video and audio routing, dynamic stream switching, and integration with cloud-based production tools. AES67-compatible audio equipment can be part of an ST 2110 environment with minimal additional configuration, protecting your investment in existing consoles and mixing desks.

Conclusion

Integrating AES67 with existing audio consoles and mixing desks transforms a facility's operational capabilities. The standard breaks down barriers between proprietary systems, reduces cabling complexity, and provides a scalable path for future growth. Whether you are connecting a vintage analog console to a modern digital network, bridging a Dante system to a Ravenna broadcast network, or preparing for SMPTE ST 2110 adoption, AES67 provides the interoperability foundation you need.

Success depends on careful assessment of existing equipment, thoughtful network configuration, and rigorous testing. By following the guidelines in this article, you can achieve a seamless integration that enhances your audio workflows without disrupting productions. With AES67 in place, your facility is ready for the next generation of audio-over-IP technology.