Introduction to AES67 Audio over IP

Professional audio has undergone a fundamental shift from dedicated point-to-point analog and digital cabling to packet-based network transport. Audio over IP (AoIP) systems now dominate broadcast, live sound reinforcement, recording, and installed sound environments because they enable flexible routing, reduced cabling costs, and centralized management. Among the many protocols and standards that have emerged, AES67 stands out as the foundational open standard for interoperability between different AoIP ecosystems. Understanding AES67 is essential for any audio engineer or IT professional who works with networked audio, as it bridges the gap between proprietary systems and provides a common language for devices from different manufacturers.

This guide explains what AES67 is, how it works, its key features, and how it fits into the broader AoIP landscape. We will also cover network requirements, practical benefits, and real-world use cases, so you can confidently design, deploy, or troubleshoot an AES67-compliant audio network.

What Is AES67?

AES67 is an open standard published by the Audio Engineering Society (AES) that specifies how high-quality, low-latency audio streams are transported over IP networks. Formally designated AES67-2015 (with updates in 2018), it defines the transport and synchronization mechanisms that enable equipment from different vendors to exchange audio without requiring proprietary gateways or translation hardware. In essence, AES67 is the “glue” that makes multiple AoIP protocols interoperable.

The standard does not prescribe a specific control protocol or discovery method; instead, it focuses on the transport layer: packet format, clock synchronization, and quality of service (QoS) parameters. This targeted scope allows existing systems like Dante, Ravenna, Livewire, and Q-LAN to support AES67 alongside their native modes, giving users a common denominator for cross-platform connectivity.

Historical Context: Why Was AES67 Created?

Before AES67, the professional audio industry faced a fragmented landscape. Dante (by Audinate) dominated live sound and corporate AV, Ravenna (by ALC Network and others) was popular in broadcast and recording, and Livewire (by Telos Alliance) was prevalent in radio. Each protocol used different transport methods, clocking schemes, and packet formats. The lack of interoperability meant that a mixing console from one manufacturer could not directly receive streams from a stagebox of another unless both shared the same protocol. This forced integrators to deploy multiple networks or expensive bridge devices.

Recognizing the problem, the AES Standards Committee formed a working group to create a common transport profile. The result was AES67, which defines a “least common denominator” for AoIP streams. By adhering to AES67, any device—regardless of its native protocol—can send and receive audio from any other AES67-compliant device, as long as the network is appropriately configured.

Key Features of AES67

AES67 brings together several critical technical elements that ensure reliable, high-fidelity audio transport over IP. Below we expand on the core features mentioned in the original overview.

Interoperability

The primary design goal of AES67 is interoperability. It achieves this by standardizing the audio payload format (Linear PCM, typically 16 or 24 bits, 48 kHz sample rate), the transport protocol (RTP over UDP/IP), and the synchronization method (IEEE 1588-2008 Precision Time Protocol, or PTPv2). Because these building blocks are universal, a Ravenna microphone preamp can talk to a Dante-enabled mixing console as long as both support AES67 mode. Similarly, a Livewire codec in a radio studio can feed an AES67-capable broadcast console without additional hardware.

Real-world interoperability is not flawless—manufacturers may implement the standard with small variations—but the AES67 compliance certification program helps guarantee that devices meet the minimum requirements. When purchasing equipment, look for the AES67 Compliance Mark or consult vendor documentation.

Low Latency

Latency is the time delay between audio input and output. In live sound reinforcement, delays over 1–2 milliseconds (ms) can cause comb filtering and feedback issues. AES67 is designed to achieve end-to-end latencies as low as 0.5–1 ms under ideal network conditions, and typically under 10 ms even in larger installations. The standard defines three latency profiles: “R” (rapid) at 1 ms, “L” (low) at 2 ms, and “M” (medium) at 10 ms. The choice depends on the application—broadcast or live sound usually uses the R profile, while installed sound may tolerate the M profile for greater robustness over long distances.

Synchronization via Precision Time Protocol (PTP)

AES67 relies on IEEE 1588-2008 Precision Time Protocol (PTPv2) to synchronize all devices on the network. PTP uses a master–slave hierarchy where a grandmaster clock sends timing packets to all slaves. Because audio sample clocks must be locked together to prevent drift and dropouts, PTP provides sub-microsecond accuracy—far beyond what NTP (Network Time Protocol) can deliver. The standard specifies a specific PTP profile (default domain 0, with certain parameters) to ensure that all AES67 devices can synchronize to a single clock source.

A stable grandmaster clock is critical. Most AES67-compliant hardware includes a built-in PTP master, or you can use a dedicated grandmaster such as the Meinberg M500 or a switch with built-in clock capabilities. The network switches themselves must support PTP boundary clock or transparent clock modes to maintain timing precision across multiple hops.

Standardized Codec and Packet Format

AES67 mandates Linear PCM audio at 48 kHz sample rate (with optional support for 44.1 kHz and 96 kHz). The audio is packed into RTP packets according to a defined “Audio Mapping” format. Each packet typically contains one or more audio channels (up to 8 per stream in the base profile, though implementations often support up to 256 channels by using multiple streams). The payload is raw PCM, so no lossy compression is applied, preserving full audio quality.

The standard also specifies how to signal stream information using Session Description Protocol (SDP). This text-based description tells receivers the IP address, port, payload type, clock identity, and sample format, enabling automatic or manual connection setup.

How AES67 Works

To understand AES67, it helps to visualize the flow of audio from a source to a destination over an IP network.

Step 1: Clock Synchronization. Before any audio flows, the PTP grandmaster clock is established. All devices must be synchronized to this clock using PTPv2. The synchronization happens continuously, with slave devices adjusting their local clocks to match the grandmaster within nanosecond accuracy.

Step 2: Stream Advertisement and Discovery. AES67 does not define a discovery protocol. Instead, stream senders (talkers) announce their available streams using SDP, which may be encapsulated in SAP (Session Announcement Protocol) or deposited on an external control system (e.g., Dante Controller, Ravenna’s RAVENNA Manager). Receivers (listeners) use the SDP to learn the stream parameters and then join the multicast group.

Step 3: Transport. Audio is packetized into RTP packets and sent over UDP/IP. AES67 typically uses IP multicast (IGMPv2/v3) to efficiently deliver the same stream to multiple recipients. Each packet includes a timestamp derived from the PTP clock, allowing the receiver to reconstruct the audio timeline and buffer the data to compensate for network jitter.

Step 4: Quality of Service (QoS). Because audio is time-sensitive, AES67 requires the network to prioritize audio packets over regular data traffic. The standard recommends using Differentiated Services (DiffServ) with a DSCP value of 46 (Expedited Forwarding) for audio RTP packets, and 34 for PTP packets. Proper QoS configuration ensures that latency and jitter remain low even when the network is busy.

Network Requirements

Implementing AES67 successfully demands a network designed for real-time traffic. Here are the key requirements:

  • Gigabit Ethernet or faster. AES67 streams can consume up to 0.64 Mbps per mono channel (16-bit, 48 kHz). A 64-channel stream uses ~41 Mbps, which is well within gigabit capacity, but multiple streams on the same switch require sufficient backplane bandwidth. 10 gigabit Ethernet is recommended for large installations.
  • Managed switches that support PTP transparent clock or boundary clock. PTP packets must be timestamped accurately at each hop. Inexpensive consumer switches often add variable delay that destroys synchronization. Look for switches from Cisco (e.g., Catalyst 3850), Netgear (M4300 series), or dedicated Pro Audio switches like the Luminex GigaCore.
  • IGMP snooping and querier. Since AES67 relies on multicast, switches must properly manage multicast group membership to avoid flooding traffic to all ports.
  • QoS configuration. Audio packets (DSCP EF) should be placed in the highest priority queue (except for PTP packets, which need even lower jitter). Non-audio traffic like file transfers or VoIP must be marked with lower priority.
  • Separate VLAN for audio (optional but recommended). Isolating audio traffic in a dedicated VLAN reduces the risk of interference from broadcast storms or rogue devices.

Interoperability with Other AoIP Systems

AES67 was designed to work as a bridge between proprietary protocols. The three most common AoIP systems that support AES67 are:

  • Dante (Audinate): Dante devices can be switched into AES67 mode via Dante Controller. In this mode, they act as standard AES67 receivers and senders. Dante uses its own control and discovery, but the audio transport follows AES67. As of Dante Domain Manager, AES67 support is integrated.
  • Ravenna (ALC Network): Ravenna was one of the early adopters of AES67. Many Ravenna devices, including the DirectOut RAVENNA-MADI converters and Merging Technologies’ Horus interfaces, support AES67 natively. Ravenna’s native mode is fully compliant, so no switching is needed.
  • Livewire (Telos Alliance): Livewire was originally a proprietary AoIP system for radio stations, but later versions added AES67 support. Telos’ Axia consoles and Omnia audio processors can send and receive AES67 streams, allowing integration with other brands.
  • Q-LAN (QSC): QSC’s Q-SYS platform uses Q-LAN, which is based on AES67 for audio transport. Q-SYS devices can directly connect to other AES67 sources and sinks.
  • ST 2110-30 (SMPTE): Broadcasters use SMPTE ST 2110 for uncompressed media over IP, and its audio component (2110-30) is essentially AES67 (with minor variations). Thus, any AES67 device can integrate with a redundant ST 2110 broadcast plant.

When connecting AES67 devices from different ecosystems, the main challenge is stream discovery and management. A Dante mixer cannot automatically see a Ravenna stream unless you manually configure the connection using the receiver’s SDP file. Many systems provide a web-based configuration page where you can paste SDP descriptions, or dedicated software like Audinate’s Dante Controller can cross-reference streams if both sides are AES67 compliant. AES also publishes an interoperability test plan to help engineers validate connections.

Benefits of Using AES67

If you are considering adopting AoIP, adding AES67 support provides clear advantages beyond any single system.

  • Vendor Independence: You are not locked into one manufacturer’s ecosystem. Mix and match microphones, consoles, loudspeaker processors, and recorders from different brands, provided they are AES67 compliant.
  • Simplified Network Design: By using a common transport, you can reduce the number of dedicated overlay networks. One IP infrastructure can handle audio, control, and even video (when using ST 2110) if QoS and VLANs are correctly set up.
  • Cost-Effective Expansion: Need to add more inputs? Buy any AES67-compliant stagebox, plug it into your switch, configure the stream—no need to match the brand of your existing console.
  • Future-Proofing: As AoIP evolves toward full IP-based production (e.g., SMPTE ST 2110 for broadcast), AES67 ensures that your audio equipment can integrate into modern, all-IP environments.
  • Reliability and Redundancy: Standard network redundancy protocols (STP, RSTP, or redundant network paths) can be applied to the audio network. AES67 does not mandate a specific redundancy method, but using switched networks with redundant links or even per-stream duplication (if supported) is possible.

Use Cases for AES67

AES67 appears in a wide variety of professional audio applications. Below are some notable examples.

Live Sound Reinforcement

In concert venues and houses of worship, digital mixing consoles from Yamaha (with Dante) and Allen & Heath (with Dante) can be connected to AES67 stageboxes from other manufacturers. For instance, a DiGiCo SD12 can receive streams from a Midas DL251 stagebox via AES67, provided both are configured correctly. The low latency (1 ms) is critical for foldback and monitor mixes.

Broadcast and Radio

Radio studios traditionally used analog or AES3 digital for audio distribution. Today, broadcasters use AoIP to distribute audio throughout the facility and even across WAN links. Axia consoles (Livewire) can share streams with WheatNet-IP or AES67-compliant codecs. The standard’s PTP synchronization ensures that network delays do not cause audio phasing or timing mismatches when mixing remote feeds.

Recording and Post-Production

High-channel-count recording systems such as Merging Technologies’ Pyramix (using Ravenna) can integrate with AES67-compliant converters from RME, Focusrite, or DAD. This allows studios to record 128+ tracks of uncompressed audio without buying into a single proprietary ecosystem. Post-production facilities also use AES67 to route audio between edit bays and machine rooms over a shared network.

Installed Sound and Corporate AV

In boardrooms, auditoriums, and museums, installed sound systems often require flexible routing for multiple zones. AES67 loudspeaker processors and amplifiers (e.g., from Symetrix, Biamp, or QSC) can receive audio from any AES67 source, allowing centralized control over IP. The scalability of multicast makes it easy to add zones without additional point-to-point cabling.

Challenges and Considerations

While AES67 is a powerful tool, it is not without challenges. Being aware of these will help you avoid common pitfalls.

  • Grandmaster Clock Dependency: If the PTP grandmaster fails and no backup exists, all synchronized devices will eventually drift, causing dropouts. Always configure a Best Master Clock Algorithm (BMCA) with multiple potential grandmasters or use hardware that can automatically elect a new master.
  • QoS Configuration Complexity: Incorrect DSCP marking can lead to packet loss or increased latency. Ensure your network switches are configured to trust DSCP tags and that audio queues are properly sized.
  • Stream Discovery Limitations: AES67 itself does not offer a unified browser. You may need to manually enter IP addresses and SDP descriptions, which can be tedious in large installations. Some manufacturers provide proprietary software that abstracts this away when both sides are from the same vendor, but cross-vendor connections often require manual setup.
  • Latency Accumulation: While per-hop latency is low, multiple hops in a large network (especially over WAN) can push total latency above tolerable thresholds. Use the appropriate latency profile and measure end-to-end delay with tools like the AES67 Latency Analyzer or a simple test tone.
  • Bandwidth Management: AES67 streams are uncompressed. A 64-channel stream at 48 kHz/24-bit uses ~73 Mbps. Overloading a gigabit network with many streams can cause congestion. Calculate total bandwidth and compare to available link capacity. Also, be mindful of multicast replication—each switch port that subscribes to a stream receives a copy, so the total load on the switch backplane must be less than its capacity.

The Future of AES67

AES67 continues to evolve. The AES67-2018 update added support for optional sample rates and clarified some QoS recommendations. Looking forward, the standard is being incorporated into broader suites such as SMPTE ST 2110 for broadcast and the AES70 (OCA) control protocol. Most importantly, AES67 is the foundation for the Audio over IP Interoperability Standard that will likely define audio transport for the next decade.

For those new to AoIP, mastering AES67 is a stepping stone to understanding advanced concepts like redundant streaming, IEEE 1722 (AVTP), and time-sensitive networking (TSN). As more manufacturers adopt AES67 as a baseline feature, the cost of entry continues to drop, making it an ideal choice for both small installations and large-scale broadcast plants.

Conclusion

AES67 is the essential open standard that enables different Audio over IP systems to work together. By standardizing transport, synchronization, and packet format, it removes the barriers that once prevented engineers from mixing equipment brands on the same network. With low latency, robust clocking via PTP, and backward compatibility with many existing protocols, AES67 has become the de facto interoperability layer for professional AoIP. Whether you are designing a new broadcast facility, upgrading a live sound rig, or building a recording studio, understanding AES67 will help you make informed decisions and create flexible, future-proof audio networks.

For further reading, refer to the official AES67 standard document and the Wikipedia article on AES67. If you are looking for practical implementation guides, Audinate offers a comprehensive whitepaper library on AoIP, and the Telos Alliance provides excellent resources on Livewire and AES67 deployment.