Understanding Aes67: A Comprehensive Guide for Audio Professionals

What Is AES67 and Why It Matters for Audio Professionals

In the professional audio industry, the shift from analog to digital has brought remarkable fidelity and flexibility, but with it came a new challenge: interoperability. Different manufacturers developed their own audio-over-IP (AoIP) solutions, creating isolated ecosystems that could not communicate with one another. AES67 was developed to break down these barriers. This open standard, released by the Audio Engineering Society in 2013, defines a common set of protocols and transport mechanisms that enable any AES67-compliant device to discover, connect, and stream audio with any other AES67 device—regardless of vendor. For audio professionals working in live sound, broadcast, recording studios, or installed sound, understanding AES67 is essential for building flexible, cost-effective, and future-proof networks. This article provides an in-depth look at AES67, its technical underpinnings, practical implementation tips, and how it compares to other popular AoIP standards.

Before AES67, audio over IP was a fragmented landscape. Dante, Ravenna, AVB, LiveWire, and Q-LAN each had their own transport mechanisms, synchronization methods, and discovery protocols. Interconnecting them required expensive gateways or proprietary converters. AES67 emerged as the universal translator, defining a minimal common profile that any vendor could implement. It did not replace existing systems but rather provided a bridge between them. Today, AES67 is widely adopted and forms the foundation for broadcast IP standards like SMPTE ST 2110.

The Core Purpose of AES67

AES67, formally known as AES standard for audio applications of networks – High-performance streaming audio-over-IP interoperability, is not a full-fledged networking protocol by itself. Instead, it specifies a set of requirements that existing protocols must meet to guarantee interoperability. The standard focuses on three key areas: transport, synchronization, and stream discovery. By mandating common profiles for RTP (Real-time Transport Protocol), PTP (Precision Time Protocol), and SAP (Session Announcement Protocol), AES67 ensures that devices from different manufacturers can exchange high-quality, low-latency audio streams without proprietary gateways.

The standard supports up to 2 channels per stream in its base implementation, but multiple streams can be combined to support higher channel counts. It operates over standard Ethernet networks using IPv4 or IPv6, making it accessible on existing IT infrastructure. Sample rates of 48 kHz and 96 kHz are supported with bit depths of 16, 20, or 24 bits. Latency is configurable but typically ranges from 1 millisecond to several milliseconds, suitable for most professional applications.

One crucial aspect is that AES67 does not dictate a specific network topology or switch requirements. Instead, it defines parameters that the network must support: multicast routing, PTP time distribution, and Quality of Service (QoS) markings for audio traffic. This flexibility allows AES67 to run over standard Gigabit Ethernet networks, though specialized switches with PTP support and low jitter are recommended for large or critical deployments.

Key Features in Detail

Interoperability Across Vendors

The primary feature of AES67 is its ability to bridge proprietary systems. For example, a Dante-based mixing console can receive audio from a Ravenna-connected microphone preamp if both are AES67-compliant. This eliminates the need for multiple network adapters or conversion boxes, simplifying system design and reducing cost. Interoperability is achieved through strict adherence to media clocking, packetization, and synchronization parameters defined in the standard. In practice, this means that a device from Yamaha (Dante) can stream audio to a device from Lawo (Ravenna) without any special configuration beyond enabling AES67 mode and setting correct PTP parameters.

Low-Latency Performance

AES67 is designed for real-time audio. It supports both unicast and multicast streaming, with multicast being the preferred method for point-to-multipoint distribution. The standard allows latency as low as 1 millisecond (in 1-millisecond packet time mode) for 48 kHz streams, though practical implementations often use 4-millisecond or 8-millisecond packet times to balance network overhead and reliability. This low latency is critical for live sound reinforcement, in-ear monitoring, and broadcast applications where delay must be imperceptible. At 4 ms packet time, end-to-end latency typically stays under 10 ms when including network propagation, buffering, and processing.

Precision Synchronization with PTP

All AES67 networks rely on IEEE 1588–2008 Precision Time Protocol (PTP) to synchronize audio clocks across devices. PTP delivers microsecond-level accuracy, ensuring that all devices sample audio at exactly the same time. This eliminates clock drift and avoids audible artifacts like pops, clicks, or phase cancellation. The standard mandates a PTP profile (often the default profile or the AES67-specific profile) with a sync interval of 1 second and an announce interval of 2 seconds. Proper PTP configuration is the most common source of problems in AES67 deployments, so network engineers must prioritize PTP traffic and ensure accurate time distribution. For mission-critical installations, using a GPS-disciplined grandmaster clock or a boundary clock in the network switch can dramatically improve stability.

Scalability for Any Size Network

AES67 scales from simple point-to-point connections to large-scale broadcast plants with hundreds of streams. Because it uses standard IP multicast, bandwidth can be managed with IGMP snooping and proper switch configuration. The standard does not impose a maximum number of devices or streams, but network capacity must be planned accordingly. With 1 Gbps Ethernet, hundreds of concurrent 48 kHz / 24-bit stereo streams can flow without issues. Higher speeds (10 Gbps or more) enable even larger systems, making AES67 suitable for stadiums, convention centers, and network audio backbones. For example, a large broadcast facility might run 200+ streams simultaneously using a 10 Gbps backbone with redundant switches.

Why AES67 Is Crucial for Modern Audio Workflows

In today's audio industry, no single manufacturer dominates all product categories. A broadcast studio might use a Lawo console (Ravenna-based), Shure wireless microphones (Dante), and Genelec monitors (AES67 via Dante or Ravenna). Without AES67, integrating these systems would require proprietary adapters or expensive conversion hardware. AES67 eliminates that friction, allowing audio professionals to choose the best tool for each job without worrying about compatibility.

Furthermore, AES67 supports high-quality uncompressed audio, meeting the demands of critical listening environments. For broadcasters, the standard enables seamless integration with ST 2110 (the SMPTE standard for professional media over IP), as AES67 forms the audio transport layer for ST 2110-30 and ST 2110-31. This makes AES67 a foundational technology for IP-based broadcast facilities transitioning from SDI to IP. In live sound, AES67 allows touring systems to integrate rental equipment from different suppliers without reconfiguring the entire network.

Adopting AES67 also future-proofs investments. Because it is an open standard not tied to any single vendor, equipment purchased today remains compatible with future systems that support AES67. This reduces long-term cost and complexity, especially in large-scale installations where technology refresh cycles are long. Additionally, AES67 has a clear upgrade path to AES X192 (currently in development), which promises higher channel densities and improved redundancy.

The Technical Foundation of AES67

Transport: RTP and Payload Types

AES67 uses RTP to carry audio data over UDP/IP networks. The standard requires support for L24 (24-bit linear PCM) payload type and allows for both 16-bit and 20-bit audio. Each RTP packet contains a fixed number of audio samples, determined by the packet time (1 ms, 4 ms, or 8 ms). The RTP header includes a timestamp derived from the PTP clock, enabling receivers to reconstruct the audio signal accurately even across non-deterministic networks. RTP also provides sequence numbers that help detect packet loss and out-of-order delivery. For redundancy, some implementations support FEC (Forward Error Correction) but this is not part of the core AES67 specification.

Synchronization: PTP and Clock Domains

The PTP grandmaster clock provides the time base for all devices. It can be a dedicated hardware device (e.g., a PTP grandmaster clock from Meinberg or an Ethernet switch with boundary clock capabilities) or a software implementation (with lower precision). All AES67 endpoints must be capable of synchronizing to the PTP domain and generating audio clocks locked to the PTP time. The standard allows for redundancy by supporting multiple PTP grandmasters in a hot-standby configuration. In practice, most AES67 deployments use a single grandmaster, often the mixing console or a dedicated clock source. The PTP domain number should be consistent across the network; domain 0 is common but some manufacturers recommend domain 1 for AES67.

Stream Discovery: SAP and Session Description Protocol

To find streams on the network, AES67 devices use SAP to announce RTP sessions. Each announcement contains a Session Description Protocol (SDP) file that describes the stream parameters: source IP, destination multicast address, RTP payload type, sample rate, number of channels, and PTP domain. Devices listen for these announcements and can then subscribe to the desired streams. Some implementations also support unicast streaming for point-to-point connections where multicast is not available or desired. SAP uses multicast address 239.255.0.1 and UDP port 9875. In larger networks, IGMP snooping must be configured to prevent SAP announcements from flooding all ports.

AES67 vs. Other AoIP Protocols

Several AoIP protocols dominate the professional audio market. Understanding how AES67 relates to them is important for system design.

Protocol	Relation to AES67	Key Differences
Dante	Audinate's Dante is a proprietary system but offers AES67 support in many products since Dante firmware 4.0. Dante devices can be configured to output AES67 streams, enabling interoperability with non-Dante equipment.	Dante uses its own clocking and discovery (Dante Controller). AES67 mode may lose some Dante-specific features (like unicast subscriptions or channel counts above 2).
Ravenna	Developed by Lawo and ALC Network, Ravenna is based on AES67 and extends it with additional features like redundant streams, higher channel counts, and flexible routing. Ravenna devices are AES67-compliant by design.	Ravenna offers more advanced network management and supports up to 256 channels per stream, while AES67 base limits to 2 channels per stream (though multiple streams can be bundled).
AVB / TSN	IEEE 1722 AVB (Audio Video Bridging) and its successor TSN (Time-Sensitive Networking) provide deterministic transport with low jitter. AES67 can run over AVB networks if configured properly, but AVB requires special switches and endpoints.	AVB/TSN guarantees bandwidth and latency, whereas AES67 relies on best-effort IP networks with PTP synchronization. AVB is more complex and expensive but offers higher reliability for critical applications.
LiveWire	Used by Axia and Telos, LiveWire is a proprietary AoIP system popular in broadcast radio. Some LiveWire devices support AES67, but not all. Interoperability often requires a gateway.	LiveWire has its own control and monitoring system, which may not be available when using AES67 mode.

For most audio professionals, AES67 acts as a universal bridge. It enables a Dante console to talk to a Ravenna I/O box, or an AVB-based microphone array to send audio to a broadcast console that only supports AES67. The key is to ensure that devices are configured properly and that the network infrastructure meets the requirements for PTP and multicast.

It is also worth noting that many modern AoIP devices support multiple modes. For example, a single switch can carry both Dante/AES67 and Ravenna/AES67 streams simultaneously, as long as they use the same PTP domain and compatible packet times. This flexibility makes AES67 an excellent choice for heterogeneous environments.

Implementing AES67 in Your Setup

Successfully deploying AES67 requires careful planning and attention to network design. Follow these steps to integrate AES67 into your audio system.

Step 1: Verify Device Compatibility

Check if your existing equipment supports AES67. Many modern Dante devices have a firmware setting to enable AES67 mode. Ravenna devices are typically AES67-ready by default. For older equipment, you may need a dedicated AES67 converter box (e.g., from DirectOut, Digigram, or Neutrik). Document the supported sample rates, packet times, and PTP profiles of each device. Some devices may require a license or firmware update to unlock AES67 functionality.

Step 2: Design the Network

AES67 functions best on a dedicated or segmented audio network using Gigabit Ethernet switches with low latency and support for IGMP snooping, PTP transparent clock or boundary clock, and quality of service (QoS) prioritization. Recommended switches include Cisco Catalyst 3850 series, Netgear M4300 series, or Luminex GigaCore series. Avoid consumer-grade switches as they may not handle multicast efficiently or add excessive jitter. For large installations, consider using a core/distribution topology with redundant links.

For PTP, designate a device as the grandmaster clock. This should be a device with a stable oscillator (preferably a PTP hardware grandmaster or a mixing console with high-precision internal clock). All other devices must be configured as slave clocks. Ensure that PTP messages are given highest priority on the network (DSCP 46 or 56 for PTP event messages). QoS should also be applied to RTP audio traffic (DSCP 56 or 46) to prevent packet loss under congestion.

Step 3: Configure PTP

Set the PTP domain number consistently across all devices (commonly domain 0 or domain 1 for AES67). Configure the grandmaster clock settings – use the AES67 profile if available. For most deployments, a two-step clock mode is recommended for accuracy. Once PTP is running, verify that all slaves report being synchronized to the grandmaster within a few microseconds. Many devices have a status LED or web interface indicating PTP lock. Use Wireshark or a PTP monitoring tool to check the grandmaster's clock accuracy and the slaves' offset.

Step 4: Set Up Streams

Using the device’s software (e.g., Dante Controller, Ravenna Network Manager, or manufacturer-specific apps), create senders and receivers. Each stream must have a unique multicast address (in the range 239.192.0.0/14 is typical for AES67). Configure the same sample rate, bit depth, and packet time on both ends. For interoperability, packet times of 1 ms, 4 ms, or 8 ms are supported – but all devices must use the same packet time for a given stream. 4 ms is a good balance because it is widely compatible and offers acceptable latency. If a device only supports 1 ms, ensure the network can handle the higher packet rate without dropping frames.

Step 5: Test and Validate

After configuration, verify that audio is flowing correctly. Listen for any glitches, dropouts, or synchronization errors. Use network diagnostic tools like WireShark with AES67 dissector, or dedicated AoIP test tools (e.g., Audio Precision APx500 with AoIP option, or N. V. L. L. A. B. tools). Check that PTP offset stays below 1 microsecond and that packet loss is less than 0.01%. Perform load testing with expected number of streams. For broadcast installations, also verify compliance with ST 2110-30 if applicable.

Step 6: Maintain and Monitor

Once the system is operational, set up ongoing monitoring. Use SNMP to track switch ports, PTP status, and stream subscription. Implement redundant PTP grandmasters if required for critical installations. Keep device firmware updated as manufacturers improve AES67 compatibility and performance. Document the network topology, IP addresses, multicast groups, and PTP settings for future reference.

Common Challenges and How to Overcome Them

Even with careful planning, AES67 deployments can encounter issues. Here are the most frequent problems and their solutions.

PTP synchronization failure: Caused by improper grandmaster selection, excessive network hops, or switches that do not support PTP transparent clock. Solution: Use switches with hardware PTP support, minimize hops, and ensure the grandmaster has a stable time source (e.g., GPS). Also verify that no other PTP domains are interfering.
Audio dropouts or distortion: Often due to network congestion, incorrect QoS settings, or mismatched packet times. Solution: Prioritize audio traffic (DSCP 56 for RTP), isolate audio network from general data traffic, and confirm all devices use the same packet time. Check for packet loss using statistics from the switch or device.
Device fails to discover streams: SAP announcements may be blocked by IGMP snooping or firewalls. Solution: Enable IGMP querier on the switch, ensure multicast is allowed, and check that SAP destination address (239.255.0.1) is routable. Some devices may need multicast to be enabled on the VLAN.
Increasing latency over time: Clock drift between devices can accumulate. Solution: Verify PTP lock quality and that devices are not falling back to free-running clock. Some devices may require periodic PTP reconfiguration. Use a dedicated grandmaster with GPS discipline for long-term stability.
Interoperability between specific devices: Some combinations may have subtle parameter mismatches (e.g., RTP payload type 96 vs. custom). Solution: Check manufacturer documentation for known compatibility modes, and contact support if needed. Sometimes using a third-party controller (like Merging’s Aneman) can help negotiate parameters.
Multicast flooding: Without IGMP snooping, multicast streams may flood all switch ports, causing bandwidth issues. Solution: Enable IGMP snooping and configure a querier. Use switch ports to limit multicast distribution to only those devices that need the stream.

The Future of AES67

AES67 continues to evolve. The AES has published updates to the standard, and it remains an active work item. One major development is its integration with SMPTE ST 2110 for broadcast production, which uses AES67 as the audio transport. As more broadcast facilities transition to IP-based workflows, AES67 will play a central role. Additionally, the Audio Engineering Society is working on AES X192, a next-generation standard that may address higher channel density, more flexible stream formats, and improved redundancy.

Another trend is the convergence of AES67 with AVB/TSN. Some manufacturers offer devices that can operate in both AES67 and AVB modes, allowing users to choose between low-cost IP networking (AES67) or guaranteed deterministic transport (AVB). As TSN switches become more affordable, hybrid networks may become common, where critical audio gets the TSN guarantee and less critical audio uses standard IP routing.

Finally, the open-source community has embraced AES67. Projects like PipeWire and Jack Audio Connection Kit have AES67 support, enabling Linux-based audio workstations to connect to professional AoIP networks. This lowers the barrier to entry for small studios and independent audio professionals. Furthermore, vendors are increasingly offering software-defined AES67 endpoints that can run on standard servers, reducing hardware costs.

As the industry moves toward all-IP infrastructures, AES67's role as the interoperability layer will only grow. The adoption of AES67 in new segments like automotive audio, intercom systems, and distributed audio is expanding the standard's reach beyond traditional pro audio.

Conclusion

AES67 has fundamentally changed how audio professionals think about networked audio. By providing a common interoperability layer, it allows equipment from different manufacturers to work together seamlessly, reducing system cost and complexity while maintaining the high performance required for professional applications. Whether you are designing a broadcast plant, a live sound tour, or a fixed installation, understanding AES67 gives you the tools to build more flexible and reliable audio networks. With proper planning, configuration, and network infrastructure, AES67 can be a powerful ally in your audio toolkit.

For further reading, consult the official AES67 specification available from the Audio Engineering Society, and explore implementation guides from vendors like Audinate and ALC Network. Practical network design tips can be found in the Broadcast Bridge article series. For a deep dive into PTP synchronization, refer to the IEEE 1588 specification and resources from Meinberg. Adopting AES67 today means investing in an open standard that continues to grow and evolve alongside the audio industry.