Implementing AES67 for Interoperable Broadcast Audio Networks

In the modern broadcast industry, the shift from traditional analog and digital point-to-point audio connections to network-based audio-over-IP (AoIP) infrastructures is accelerating. As broadcasters build increasingly complex and distributed production environments, the need for a universal, interoperable standard becomes critical. AES67, an open standard developed by the Audio Engineering Society, fills this gap by providing a common language for high-performance audio-over-IP devices from different manufacturers. This article explores what AES67 is, its key features, detailed implementation steps, benefits, and best practices for building reliable, scalable broadcast audio networks.

Today’s broadcast facilities often contain a mix of equipment from various vendors—digital audio consoles, microphone preamps, intercom systems, codecs, and more. Without a unifying standard, integrating these components can require proprietary converters, complex signal routing, or a single-vendor ecosystem. AES67 eliminates these barriers by defining the transport, synchronization, and encoding formats necessary for seamless interoperability, enabling broadcasters to choose best-of-breed components and design networks that are flexible, future-proof, and cost-effective.

What Is AES67?

AES67 is an open, application-independent standard for transporting linear, uncompressed digital audio over IP networks. Ratified in 2013 by the Audio Engineering Society (document number AES67-2015, updated in 2018), it defines a common set of parameters for audio stream transport, including sampling rates, bit depths, packet sizes, and synchronization mechanisms. Unlike proprietary AoIP protocols such as Dante, RAVENNA, or Livewire, AES67 is not a full-fledged protocol suite—it is a interoperability mode that any AoIP technology can implement to communicate with other AES67-compliant devices. This makes it a critical bridge between different audio networking ecosystems.

AES67 is built on existing network standards: it uses the Real-time Transport Protocol (RTP) for audio data transport, User Datagram Protocol (UDP) for network transmission, and the Precision Time Protocol (PTPv2 per IEEE 1588-2008) for clock synchronization. It supports sampling rates of 48 kHz and 96 kHz, bit depths of 16 or 24 bits, and packet times ranging from 1 ms to 4 ms (for 48 kHz audio). Its low-latency profile permits end-to-end delays as low as 250 microseconds in tightly configured networks, making it suitable for live broadcast and performance environments.

AES67 is also a foundational element of the more comprehensive SMPTE ST 2110 suite, which standardizes separate video, audio, and ancillary data streams over IP for professional media production. In the broadcast world, AES67 acts as the audio component within ST 2110-30, allowing audio streams to coexist with video and metadata on the same IP network.

Key Features of AES67

Understanding the core features of AES67 helps broadcasters appreciate its value and navigate the implementation process. The standard is designed to prioritize interoperability, low latency, audio quality, synchronization, and scalability.

Interoperability

AES67’s primary goal is to enable devices from different manufacturers to exchange audio streams without proprietary gateways or conversion hardware. When a device claims “AES67 compliance,” it guarantees it can send or receive audio using the defined RTP payload format (L24 for linear PCM) and PTP clocking. This allows a mixing console from one brand to directly receive microphone signals from an AES67-enabled stagebox from another vendor, or to network with an intercom system from a third. The standard also defines how devices discover each other via multicast DNS (mDNS) and DNS Service Discovery (DNS-SD), streamlining the setup process.

Low Latency

Live broadcast and production demand extremely low latency—typically under 5 milliseconds end-to-end. AES7 supports packet intervals as short as 1 ms (with 48 samples per packet at 48 kHz) to keep latency minimal. Combined with high-performance network switches and careful QoS configuration, broadcasters can achieve deterministic, sub-millisecond network delays. However, the achievable latency depends on the entire signal chain: network switches, PTP synchronization accuracy, and the latency added by each device’s internal processing must all be considered.

High Audio Quality

AES67 transports uncompressed linear PCM audio, preserving full fidelity from source to destination. It supports 48 kHz and 96 kHz sampling rates with 16 or 24-bit resolution, ensuring professional-grade audio that meets broadcast requirements for clarity and dynamic range. Because compression is not applied, the standard avoids codec-induced artifacts and is ideal for mission-critical audio where integrity is paramount.

Accurate Synchronization via PTP

Precision Time Protocol (PTPv2, IEEE 1588-2008) is the synchronization backbone of AES67. All devices on the network synchronize to a common grandmaster clock, ensuring that audio samples are captured and played back at the same rate across multiple endpoints. Without this synchronization, packet jitter and clock drift would cause audio glitches, pops, or mismatched timing between channels. PTP achieves accuracies in the microsecond range over standard Ethernet, which is sufficient for sample-accurate alignment of audio streams.

Scalability

AES67 networks can scale from a few devices in a single control room to hundreds of channels across large broadcast campuses or distributed productions. Because it uses standard IP multicast, one sender can reach many receivers without replicating the stream for each one. The standard also allows for redundant stream transmission (source-specific multicast, or SSM) for failover protection. With careful network design—subnetting, IGMP snooping, and bandwidth provisioning—broadcasters can grow their audio infrastructure incrementally while maintaining performance.

Implementing AES67 in Broadcast Networks

Putting AES67 into practice involves more than just plugging in cables. A successful deployment requires careful planning of hardware compatibility, network configuration, synchronization management, and verification testing. Below we outline the essential steps.

Step 1: Selecting Compatible Hardware

Start by auditing your current and planned equipment for AES67 support. Many professional audio manufacturers now include AES67 compliance in their products. For example, mixing consoles from manufacturers like Lawo, Studer (Soundcraft), and Calrec support AES67 natively or via additional cards. Stageboxes from Yamaha (via the RMio64-D), RME, and Neumann also offer AES67 compatibility. Network switches must support IGMP snooping, PTP transparent clock or boundary clock functionality, and Quality of Service (QoS) priority queuing (e.g., DiffServ DSCP). Both managed and unmanaged switches can be used, but managed switches give you the control needed for QoS and PTP configuration. When selecting new gear, verify that the manufacturer explicitly lists AES67 compliance and details which RTP payload types (L16, L24, AM824) and packet times are supported.

Step 2: Network Configuration and Quality of Service (QoS)

To ensure reliable, low-latency audio, you must prioritize AES67 traffic over other network traffic. Configure your switches to map the DSCP (Differentiated Services Code Point) values used by AES67 to the highest priority queues. AES67 recommends a DSCP value of 46 for audio RTP packets (which is mapped to Expedited Forwarding per-hop behavior). PTP event messages should use DSCP 46 as well, while network management traffic can use lower values. Additionally, set up IGMP snooping to ensure multicast streams are only sent to ports that have subscribed, reducing unnecessary bandwidth consumption. For large networks, use Layer 3 routing to segment multicast domains and prevent unnecessary flooding. Ensure all switches support jumbo frames? While AES67 packets are small (typically 48 to 144 bytes payload + headers), jumbo frames (up to 9000 bytes) are not required but may be used for longer packet times. Keep MTU settings at 1500 bytes for compatibility.

Step 3: PTP Synchronization Setup

Proper PTP synchronization is vital. Designate one device as the Grandmaster Clock (GM). Preferably, choose a dedicated PTP grandmaster or a high-quality audio device with a stable internal oscillator (e.g., a master clock generator with network synchronization capability). Use PTP version 2 (IEEE 1588-2008) with the profile defined in AES67 (or the ITU-T G.8265.1 profile for telecom/multicast). Configure all endpoints to accept the GM clock. Ensure your network switches support PTP transparent clock or boundary clock to minimize timing accumulation across hops. In a pure Layer 2 domain, a transparent clock can measure and correct packet delay variation; in routed networks, use boundary clocks as PTP-aware nodes. Verify synchronization by checking offset values; they should stay below ±1 microsecond for best performance. Many AES67 devices provide status indicators for PTP lock.

Step 4: Audio Stream Routing and Discovery

AES67 relies on multicast RTP for audio transport. Devices advertise available streams using the Session Description Protocol (SDP), which includes information like IP address, port, payload type, sampling rate, and channel count. The standard’s recommended discovery method is DNS-SD via mDNS, which allows devices to automatically publish and locate streams on the same subnet. For inter-subnet communication, you may need a DNS server with dynamic updates or use static SDP files. Many AES67 control applications (often provided by the equipment vendor) allow you to easily route audio by selecting sender and receiver streams. If you need more advanced routing, you can integrate with protocols like NMOS IS-04 and IS-05 (part of the SMPTE ST 2110 ecosystem) for discovery and connection management, though these are optional on top of AES67.

Step 5: Testing and Verification

After configuration, perform systematic testing. Start by connecting a single sender and receiver, and check for audio continuity using a tone generator and analyzer. Use network monitoring tools (like Wireshark with AES67 dissector) to inspect RTP headers and PTP messages. Verify latency using a timecode or by injecting a known audio waveform and measuring the delay at the receiver. Test for packet loss: even one lost packet per minute can cause audible clicks in uncompressed audio. Monitor PTP offset, jitter, and Follower Sync messages. Also test failover—if your network supports multicast redundancy (SSM or source-specific multicast), ensure the receiver can switch to a backup stream within a few milliseconds without audio dropout. Document all configurations for future maintenance.

Benefits of AES67 for Broadcast Audio

Adopting AES67 brings tangible advantages to broadcast facilities, from reduced capital expenditure to operational agility.

Vendor Independence. Broadcasters can mix and match equipment from different manufacturers without being locked into a single ecosystem. This drives competition and often results in better pricing and innovation. For example, you can pair an AES67-enabled console from one brand with stageboxes from another, or route audio to a third-party codec for remote contribution.

Scalable Architecture. Adding channels or devices becomes simpler. Expanding from 64 channels to 256 often requires only additional switches or better cabling, not a new matrix frame. Multicast distribution means one source can feed many destinations without any physical or routing limitations.

Simplified Cabling and Infrastructure. A single Ethernet cable can carry hundreds of audio channels, control data, and even video in an ST 2110 environment. This reduces copper weight, conduit space, and power consumption. Broadcasters transitioning from MADI or AES3 can drastically cut cabling costs.

Remote Production and Distributed Workflows. AES67 works over wide-area networks when managed correctly (e.g., using VPNs with QoS). This enables remote audio mixing, connecting a studio at one location with an OB van at another, or distributing monitoring across multiple control rooms. The standard’s reliance on standard IP means it can piggyback on existing corporate infrastructure with proper isolation.

Future-Proofing. Because AES67 is an open standard and a building block for SMPTE ST 2110, it will remain relevant as broadcast moves fully to IP. Many manufacturers now design new products to support AES67 as a baseline, ensuring compatibility with upcoming generations of gear.

Common Challenges and Troubleshooting

Implementing AES67 is straightforward, but issues can arise. Understanding common pitfalls helps prevent headaches.

PTP Synchronization Problems. The most frequent issue is PTP lock failure or excessive offset. Causes include mixed PTP profiles (e.g., one device set to default 1588-2002, another to 2008), improperly configured boundary clocks, or network switches that do not handle PTP transparently. Ensure all devices use the same PTP version and profile (preferably the AES67 recommended profile). Use a dedicated PTP grandmaster if possible, preferably with GNSS or IEEE 1588 Stratum 1.

Multicast Configuration Errors. If a receiver cannot hear a stream, check IGMP snooping—it might be disabled or misconfigured, preventing the switch from forwarding multicast to the receiver’s port. Also verify that multicast routing is enabled across subnets if the sender and receiver are on different VLANs or subnets.

Bandwidth Overload. Although AES67 streams are small, many streams can saturate a 1 Gbps link. For example, 256 channels at 48 kHz/24-bit with 1 ms packets consume about 384 Mbps (each stream is ~1.5 Mbps per channel). Use link aggregation (LAG) or upgrade to 10 Gbps for large installations.

Incompatibility Due to Payload Format Variance. Some older AES67 implementations may support only L16 (16-bit) while newer ones support L24 (24-bit). Ensure both sender and receiver are configured for the same payload type. Likewise, packet time differences (e.g., 1 ms vs 4 ms) can cause interoperability issues; the standard mandates support for 1 ms, but not all devices honor this.

Network Jitter. Even with PTP, network jitter from congestion or switch buffering can cause packet arrival times to vary. Configure jitter buffers on receivers appropriately—most AES67 devices allow buffer adjustment from 1 ms to 50 ms. For live production, keep buffers as low as possible (e.g., 5 ms) while avoiding dropouts.

Conclusion

AES67 represents a critical step toward standardized, interoperable audio-over-IP in the broadcast industry. Its openness, low latency, high audio quality, and scalability make it an ideal choice for broadcasters who need to connect diverse equipment without sacrificing performance. By carefully selecting compatible hardware, tuning network QoS, and synchronizing PTP properly, broadcast engineers can build reliable audio infrastructures that are easy to expand and maintain. As the industry continues to migrate toward fully IP-based production environments, AES67 will remain a foundational technology—either as a standalone protocol or as the audio backbone of SMPTE ST 2110. Embracing AES67 today positions broadcasters for a flexible, future-ready audio network.

For further reading, see the official AES67 standard page, the Wikipedia entry on AES67, and the SMPTE ST 2110 suite overview.