Origins of AES67

Before the adoption of AES67, the professional audio industry operated within a fragmented ecosystem of proprietary audio-over-IP (AoIP) protocols. Major players such as Audinate’s Dante, ALC NetworX’s RAVENNA, and Wheatstone’s Livewire each delivered robust, low-latency solutions, but they could not communicate directly with one another. This lack of interoperability forced system integrators and broadcasters to commit to a single vendor ecosystem, limiting flexibility and driving up costs. The Audio Engineering Society (AES) recognized the need for a universal standard that would allow these protocols to coexist and exchange audio streams seamlessly.

Work on AES67 began in 2011 under the AES Standards Committee’s SC-02-12 working group, which brought together engineers from leading manufacturers, broadcasters, and research institutions. The standard was formally published in September 2013 as AES67-2013: AES Standard for Audio Applications of Networks – High-performance streaming audio-over-IP interoperability. It defined a baseline set of requirements that any compliant device must meet, focusing on timing, transport, and media format compatibility. Critically, AES67 did not replace existing protocols but instead created a common language—a “bridge”—that allowed them to interconnect. This approach enabled manufacturers to add AES67 support alongside their native protocols, gradually building an interoperable ecosystem.

Major Milestones in AES67 Evolution

The standard has undergone several revisions and extensions since its initial publication. Each milestone has addressed emerging challenges and incorporated lessons from real-world deployments, ensuring that AES67 remains relevant as network speeds and production workflows evolve.

2013: Initial Release – Establishing the Baseline

The original AES67-2013 standard defined core elements: sampling rates up to 96 kHz, bit depths of 16 or 24, and transport using RTP (Real-time Transport Protocol) over UDP. It mandated the use of IEEE 1588 Precision Time Protocol (PTP) for clock synchronization and specified multicast address ranges for efficient bandwidth utilization. This release provided a solid foundation, but early adopters faced issues with network configuration and jitter management. Despite these challenges, the standard quickly gained traction, as it offered a clear path for multi-vendor interoperability.

2015: Refinements and Clarifications

An amendment published in 2015 (AES67-2015) clarified several technical ambiguities, particularly around PTP profile selection and packet timing. It also introduced optional support for redundant streams, improving reliability in mission-critical broadcast applications. These refinements made AES67 more practical for large-scale deployments and reduced the configuration burden on network engineers.

2018: Enhanced Synchronization and Clock Accuracy

The AES67-2018 update was a major step forward. It tightened the allowed PTP variance (master‑slave offset) from ±1 ms to ±1 µs, dramatically improving sample-level alignment across multiple devices. This update also added support for the AES67-2018 “Class A” profile, which guaranteed sub‑millisecond latency even over complex network topologies. Additionally, the standard began to align with SMPTE ST 2110, paving the way for combined audio/video‑over‑IP workflows. This revision was critical for broadcasters who needed to synchronize hundreds of audio channels with video frames.

2021: Integration with SMPTE and Media Transport

Published as AES67-2021, this revision formalized interoperability with SMPTE ST 2110-30 (audio) and ST 2110-31 (audio in AES3 format). It also introduced the concept of “media profiles” that bundled specific timing, format, and redundancy parameters into pre‑defined configurations, making it easier for manufacturers to certify compliance. The 2021 release explicitly addressed the needs of broadcasters transitioning to IP infrastructures for both audio and video, and it included provisions for handling audio metadata such as loudness and language tags.

2024: Real-World Performance Enhancements

Although the latest official update is AES67-2021, ongoing work within the AES and the IEEE Audio/Video Bridging Task Group has led to practical refinements published as amendments. The 2024 series of documents provided detailed guidance on network design for AES67 over 25 GbE and 100 GbE links, ensuring the standard remains relevant as studios upgrade to higher bandwidth. These updates also included improved error resilience algorithms and recommendations for encrypted media transport, reflecting the growing emphasis on security in live production environments.

Technical Architecture of AES67

To understand why AES67 has endured, it helps to examine its core technical components and how they interact to deliver low‑latency, synchronized audio over standard IP networks.

Clock Synchronization: IEEE 1588 PTP

AES67 relies on the IEEE 1588 Precision Time Protocol (PTP) for precise clock alignment. All devices in an AES67 network synchronize to a grandmaster clock, which distributes timing messages at regular intervals (typically once per second). The standard mandates the use of the “Default PTP Profile” for AoIP, although updated versions also support the “SMPTE ST 2110 Profile” for hybrid workflows. With the 2018 revision, the maximum allowed clock deviation dropped to 1 µs, ensuring that multiple microphones and studio monitors remain sample‑accurate across hundreds of channels. This level of precision is essential for phase‑coherent microphone arrays and for avoiding comb‑filtering artifacts in live sound reinforcement.

Audio Transport: RTP over IP Multicast

AES67 uses RTP (Real‑time Transport Protocol) to encapsulate uncompressed audio samples. Each stream is addressed to a multicast IP group, allowing multiple receivers to subscribe without overloading the source. The packetization scheme packs a fixed number of samples per packet (typically 1 ms of audio, or 48 samples at 48 kHz) to balance latency and overhead. The standard also defines how to handle packet loss through optional FEC (Forward Error Correction) and redundancy streams. In practice, network engineers configure switches with IGMP snooping and multicast filtering to optimize bandwidth utilization.

Media Formats and Bit Rates

AES67 supports linear PCM audio with sample rates of 48 kHz, 96 kHz, and (since the 2018 update) 192 kHz. Bit depths are either 16 or 24 bits. Channels are grouped into “audio flows” that can carry up to 8 channels per flow (mono, stereo, or 5.1). The standard also defines how to encapsulate AES3 digital audio (including embedded metadata) within RTP streams, ensuring compatibility with legacy equipment. For immersive audio formats such as Dolby Atmos, multiple flows can be combined to handle up to 128 channels or more, though this requires careful network planning.

Network Requirements: QoS and Bandwidth

Deploying AES67 requires a managed Ethernet network with explicit Quality of Service (QoS) marking. The standard recommends using DiffServ codepoints to prioritize audio packets over ordinary data traffic. For a 48 kHz, 24‑bit, 8‑channel flow, the approximate bandwidth is 30 Mbps. With Gigabit Ethernet becoming standard, even large studios can run hundreds of channels without congestion. The 2024 amendments provided specific recommendations for jumbo frames (up to 9000 bytes) to reduce packet overhead in high‑channel‑count environments. Additionally, network switches must support strict priority queuing and traffic shaping to maintain deterministic latency.

Current Features of AES67 in Practice

Today, AES67 is embedded in thousands of products from dozens of manufacturers, including mixing consoles, amplifiers, microphones, and signal processors. Its key features can be summarized as follows:

  • Universal Interoperability: Devices supporting Dante, RAVENNA, Livewire, or Q‑LAN can be linked via an AES67 gateway or natively, provided they implement the standard. This allows broadcasters to mix and match equipment from different vendors without sacrificing performance.
  • High‑Precision Synchronization: Using IEEE 1588 PTP with 1 µs accuracy, AES67 networks can handle live broadcast events with multiple cameras and sound sources without dropouts or phase errors.
  • Scalability: Multicast streaming allows one source to feed hundreds of destinations. The use of standard Ethernet switches means system size is limited only by network capacity, not by proprietary protocol constraints.
  • Low Latency: End‑to‑end latency as low as 125 µs (one audio packet at 8 kHz sampling) is achievable in optimized networks, meeting the demands of live sound reinforcement and in‑ear monitor (IEM) systems.
  • Control Integration: AES67 works alongside AES70 (OCA) for remote device control and monitoring, enabling unified management of large IP‑based audio systems.
  • Redundancy Options: The standard supports redundant streams over separate network paths (using the PRP or HSR protocols in some implementations), ensuring failover in critical broadcast applications such as live sports or news production.

Industry Adoption and Interoperability Examples

AES67’s success is best illustrated by its adoption in major broadcast facilities and live events. For instance, the BBC’s new Broadcasting House in London uses AES67 to interconnect audio consoles from multiple vendors, including Calrec and Lawo. Similarly, the 2024 Olympic Games broadcast relied on AES67‑compliant intercom systems from Riedel to link hundreds of commentator positions across different venues.

Manufacturers have also embraced AES67 as a standard feature. Audinate’s Dante platform, originally proprietary, now includes native AES67 support (enabled via firmware updates) to allow Dante devices to work alongside RAVENNA‑based systems. Likewise, ALC NetworX’s RAVENNA protocol has always been AES67‑compliant, and its integration with SMPTE ST 2110 makes it the backbone for many IP‑based TV production trucks. Wheatstone’s Livewire also provides AES67 support, allowing radio broadcasters to seamlessly integrate IP audio with existing analog or digital infrastructure.

Interoperability testing events, such as the annual AES67 PlugFest, bring together engineers from different companies to verify that their implementations interoperate correctly. These events have helped refine the standard and reduce integration issues in the field. The AES Technical Committee on Networking also publishes conformance test suites that manufacturers can use during product development.

What to Expect in Future Releases

As professional audio continues its migration to IP‑based workflows, the AES67 standard will need to evolve to meet new requirements in security, bandwidth, and media diversity. Based on current industry trends and ongoing work within the AES Standards Committee, the following areas are likely to receive focused attention in upcoming revisions.

Enhanced Security: Encryption and Authentication

Today, AES67 streams are typically sent without encryption, which poses risks in broadcast and event environments where proprietary content (e.g., live sports commentary or unedited studio feeds) could be intercepted. Future releases are expected to specify mandatory or optional encryption using AES‑128 or AES‑256, along with key management protocols such as DTLS (Datagram Transport Layer Security). Authentication mechanisms will prevent unauthorized devices from joining or injecting traffic into the network. The goal is to achieve security on par with modern IP video standards (e.g., SMPTE ST 2110 with SRTP). Some manufacturers have already implemented proprietary encryption on top of AES67, but a standardized approach will simplify multi‑vendor deployments.

Higher Bandwidth and Channel Count

Immersive audio formats like Dolby Atmos, MPEG‑H, and 3D audio require more channels and higher sample rates. Future AES67 profiles may support up to 256 channels per flow and sample rates up to 384 kHz. As studios adopt 25 GbE and 100 GbE networks, the standard will provide explicit packetization and timing recommendations to exploit these higher link speeds without increasing jitter. The 2024 amendments already offered guidance for 25 GbE, and future releases are expected to extend this to 50 GbE and 200 GbE. This will enable direct handling of object‑based audio without the need for multiple aggregated flows.

Improved Interoperability with Emerging Protocols

New transport protocols such as AVB (Audio Video Bridging) and TSx (Transport Stream extensions) are gaining traction in both professional and consumer domains. Future AES67 releases may define “bridging rules” that allow seamless conversion between AES67 streams and AVB streams (using IEEE 1722) or MPEG Transport Streams. This would enable direct interconnection between professional AoIP networks and consumer IoT audio devices, opening up new production‑to‑home distribution models. Additionally, the AES is exploring ways to harmonize AES67 with the emerging IEEE 802.1BA standard for time‑sensitive networking (TSN), which would provide deterministic latency guarantees across heterogeneous networks.

Integration with Cloud and Edge Computing

The rise of cloud‑based production and remote broadcasting requires AoIP to operate over WAN connections with variable latency and potential packet loss. Future AES67 might specify a “WAN Profile” that uses adaptive jitter buffers and FEC tailored for packet loss rates up to 10%. Additionally, the standard could define how to encapsulate AES67 in SRT (Secure Reliable Transport) or RIST (Reliable Internet Stream Transport) for reliable long‑distance transport. This would allow broadcasters to send live audio streams from remote locations (e.g., sporting events or news gathering) directly into a cloud‑based mixer with minimal latency.

Unified Time and Metadata Alignment with Video

Although AES67 already works with SMPTE ST 2110, tighter integration is anticipated. Future versions may mandate a shared grandmaster clock across both audio and video domains, eliminating the need for separate time bases. They may also define standard metadata containers for loudness, language, and source labeling, making it easier to manage complex multi‑language broadcasts (e.g., for sports events with multilingual commentary tracks). Alignment with the IEEE 1588‑2019 amendment for redundant grandmaster clocks would further enhance reliability in mission‑critical production environments.

Energy Efficiency and Low‑Power Designs

With sustainability becoming a priority, future AES67 releases may include guidelines for reducing power consumption in AoIP devices. This could involve dynamic adjustment of packet rates during idle periods, support for energy‑efficient Ethernet (IEEE 802.3az), and recommendations for low‑power hardware designs that still meet strict timing requirements. Network switches optimized for AES67 with per‑port power management could significantly reduce the carbon footprint of large‑scale installations.

Conclusion

AES67 has come a long way from its origins as a basic interoperability framework. Today it is a mature, widely trusted standard that underpins the audio‑over‑IP revolution in broadcasting, live sound, and media production. Each revision—from 2013 through 2021 and beyond—has been driven by real‑world needs: tighter sync, higher bandwidth, better redundancy, and alignment with video. As the industry moves toward immersive audio, cloud workflows, and heightened security demands, future AES67 releases will continue to provide the essential glue that allows diverse devices and protocols to speak the same digital language. For system designers, broadcast engineers, and integrators, staying abreast of these changes is not just a matter of technical curiosity—it is essential for building reliable, future‑proof installations that can adapt to the next generation of audio networking.

For the latest official updates, check the AES Standards website and the IEC framework for international harmonization. Many manufacturers also publish detailed white papers on their implementation strategies—these are invaluable for understanding how AES67 works in practice. Additionally, RAVENNA’s white papers and Audinate’s training resources offer practical guidance for network design and troubleshooting.