In modern professional audio, the ability to connect disparate systems from different manufacturers without sacrificing performance is no longer a luxury—it is a requirement. AES67 emerged as a critical standard to solve this exact problem, enabling high-quality, low-latency audio streaming over IP networks while ensuring that equipment from competing ecosystems can work together. This article dives deep into the compatibility and interoperability of AES67 with other audio protocols, offering practical insights for engineers, integrators, and educators looking to build robust, future-proof audio networks.

What Is AES67?

AES67 is an open, royalty-free standard published by the Audio Engineering Society (AES) in 2013. It defines a set of specifications for transporting professional audio over IP networks using widely adopted technologies: RTP (Real-time Transport Protocol) for audio payload, PTPv2 (Precision Time Protocol, IEEE 1588-2008) for synchronization, and SIP/SDP (Session Initiation Protocol / Session Description Protocol) for connection management. By relying on these existing standards rather than proprietary schemes, AES67 provides a common ground that any willing manufacturer can implement.

The standard supports up to 64 channels of uncompressed 24-bit, 48 kHz audio per flow, with sample rates up to 96 kHz, and guarantees deterministic latency as low as 1 millisecond. Its primary mission is not to replace proprietary protocols but to act as an interoperability bridge—a “lowest common denominator” that allows audio streams to move freely between different islands. This approach has made AES67 the backbone of many large-scale installations, from broadcast studios to live sound reinforcement and corporate AV systems.

How AES67 Enables Interoperability

AES67 achieves interoperability by mandating a common set of transport and timing parameters. Any AES67-compliant device must implement:

  • RTP payload formats: Using L24 (uncompressed linear PCM) and sometimes AM824 (MADI over IP).
  • PTPv2 for clock synchronization: All devices share a grandmaster clock, keeping sample clocks locked within ±1 μs (microsecond) accuracy.
  • SDP-based stream discovery and management: Sessions are described through SDP files that contain necessary details (IP address, port, sample rate, channel count).
  • Standardized network parameters: Minimum QoS requirements, specified packet sizes (e.g., 1 ms packet time), and multicast addressing using IGMP.

When a proprietary protocol like Dante, Ravenna, or Livewire wants to “speak” AES67, it must map its internal transport mechanism onto these common parameters. This often requires a configuration step where the device is told to switch into AES67 mode or to enable an interoperability profile. Once active, the device can send and receive RTP streams using the same timing reference as any other AES67 node, regardless of its native protocol.

AES67 Compatibility with Major Audio Protocols

Dante

Developed by Audinate, Dante is by far the most widely deployed audio-over-IP protocol in professional and commercial installations. Dante uses proprietary transport (Dante Audio) and its own clocking, but most modern Dante devices include an AES67 mode. In this mode, Dante interfaces can output RTP streams that comply with AES67 timing and addressing, while still coexisting with native Dante traffic on the same network. For example, a Yamaha QL5 console connected via Dante can stream AES67 audio to a Ravenna-based Neumann microphone preamp. However, Dante’s AES67 implementation may limit certain features—such as redundant network paths or seamless redundancy—typically requiring a dedicated configuration profile. The Audinate website provides detailed lists of which Dante devices support AES67 and the firmware versions required.

Ravenna

Ravenna, originally developed by ALC (now part of the DirectOut family), is an open audio-over-IP technology that uses a very similar stack to AES67—in fact, AES67 was heavily influenced by Ravenna. Ravenna devices are often AES67-compliant by design, making them natural partners in multi-protocol networks. Many Ravenna products (from manufacturers like Neumann, Merging Technologies, and DirectOut) advertise native AES67 support. In practice, a Ravenna stream can be sent directly to a Dante device in AES67 mode without any transcoding. Ravenna also supports higher sample rates and redundant streams via its proprietary extensions, but these are not part of the AES67 baseline. The Ravenna website offers a wealth of technical documentation and a list of compliant devices.

Livewire

Livewire, from the Telos Alliance, is a digital audio network designed primarily for broadcast applications. Its latest generation, Livewire+, incorporates native AES67 support. Earlier Livewire nodes use a proprietary protocol over Ethernet, but the newer gateways and blades (e.g., Axia products) can be configured to bridge Livewire audio into AES67 streams. This allows broadcast consoles (like the Axia Element) to feed AES67-aware codecs or intercom systems. Care must be taken with PTP timing: Livewire uses its own clocking (based on Windows Media Audio timing). To make AES67 work, a PTP grandmaster clock must be injected into the network. Telos Alliance’s support pages detail the necessary configuration steps for AES67 interoperability.

Q-Lan

Q-Lan is the proprietary audio networking protocol developed by QSC for their Q-SYS ecosystem. While QSC largely uses its own Q-Lan for internal DSP routing, modern Q-SYS cores and peripherals support AES67 as an input/output option. This enables Q-SYS systems to receive AES67 streams from Dante or Ravenna devices and vice versa. For example, a QSC Core 510i can act as a bridge between a Dante-equipped microphone and a Q-Lan loudspeaker. QSC provides clear documentation on configuring AES67 on their official site.

AVB / TSN

Audio Video Bridging (AVB, now part of Time-Sensitive Networking TSN) is a family of IEEE standards that ensure guaranteed bandwidth and low latency over Ethernet. AES67 often runs over standard Ethernet switches using QoS, but AVB/TSN offers more deterministic performance. Some AVB-enabled devices (like those from Biamp or L-Acoustics) can also generate AES67 streams, but the mapping is not always direct. Generally, AES67 can tunnel over AVB networks by reserving bandwidth, but full interoperability requires careful configuration of stream reservations (SRP). The IEEE 802.1 AVB Task Group provides the foundational specs.

Practical Implementation Considerations

Configuration Profiles

To achieve AES67 interoperability, each device must be placed in its “AES67 mode.” This typically disables proprietary enhancements (like redundant streams) and forces standard RTP packet sizes, usually 1 ms or 125 µs. Many manufacturers provide preset profiles; for instance, Audinate’s Dante Controller includes an “AES67 Config” button that sets all parameters automatically. Always check the device manual to confirm the exact steps—missing a setting (like disabling encryption) can cause silent failures.

Synchronization (PTP)

PTPv2 is non-negotiable. Every AES67 device must be slaved to the same grandmaster clock. In a mixed-protocol network, you must ensure only one PTP grandmaster is active and that all switches are “transparent clocks” or “boundary clocks” if your network spans multiple subnets. Some legacy switches (without 802.1AS support) may introduce jitter that breaks AE67 timing. I recommend using a dedicated PTP grandmaster such as the Seiko Time Systems SyncServer or the Meinberg LANTIME, especially in larger installations. A simple but effective test is to run ptp4l (Linux) or the PTP Monitoring tool on a management PC to check clock offset across all devices.

Latency and QoS

AES67’s default latency is 1 ms, but many devices allow you to increase it (to 2, 4, or 10 ms) for stability over long or congested networks. Each switch hop can add 100–500 μs, so plan your topology accordingly. QoS must be enabled: the standard recommends assigning PTP traffic (DSCP 56 or 63) the highest priority, followed by audio RTP (DSCP 34–46), then best-effort. Misconfigured QoS is the most common cause of dropouts; use your switch’s LLDP or NetFlow to verify queue assignments.

Testing and Troubleshooting

  • Packet analysis: Wireshark can decode AES67 streams (look for RTP payload L24). Check for sequence errors or PTP offset drifts.
  • Network validation: Tools like XLAB’s AES67 Test Suite (commercial) or open-source scripts can verify compliance.
  • Common pitfalls: Mixed VLANs, multiple PTP grandmasters, and unsupported switch models. Also, note that AES67 does not support encryption natively—secure networks must use IPsec or separate VLANs.

Benefits and Challenges of AES67 Interoperability

The primary benefit is vendor diversity: you are no longer locked into a single ecosystem. A church AV system can pair a Dante mic with a Ravenna processor and a Livewire broadcast console. Costs drop because you can choose the best tool for each function. Scalability improves because AES67 networks can span multiple sites via WAN if latency is managed. Additionally, many cloud-based DSP platforms (like those from Q-SYS and Biamp) now accept AES67 streams, simplifying remote production.

However, challenges remain. Proprietary features (such as Audinate’s Dante Domain Manager or Ravenna’s redundant streams) are lost when operating in AES67-only mode. Configuration can be error-prone—a single wrong PTP parameter can bring down the entire audio network. Also, AES67 does not specify any plug-and-play discovery; you may need to manually exchange SDP files or use a control system (like Crestron) for routing. Finally, not all devices support AES67 equally; some impose channel or sample-rate limitations. Always verify using the manufacturer’s “AES67 compliance matrix.”

Future of AES67 and Audio-over-IP Interoperability

AES67 has laid the foundation for a broader standard: SMPTE ST 2110, which is now required in broadcast environments for video-over-IP, with AES67 used as the audio transport. The two standards work together seamlessly. Additionally, the Audio Engineering Society is developing AES67-2020 (updated for sample rates up to 384 kHz). Meanwhile, newer protocols like NDI and AV1 are exploring further integration, but AES67 remains the go-to for uncompressed, low-latency interoperability. Expect more AVB/TSN switches to become cost-effective, making AES67 networks even more deterministic over standard infrastructure.

Conclusion

AES67 is not a protocol that competes with Dante, Ravenna, or Livewire; instead, it bridges them. By understanding its underlying mechanics—RTP streaming, PTP timing, and SDP session management—audio professionals can design networks that combine best-of-breed devices from multiple manufacturers. Whether you are upgrading a radio station, fitting a performing arts center, or building a distributed conferencing system, AES67 gives you the freedom to mix and match while maintaining the tight synchronization and low latency that professional audio demands. As the industry continues to converge on IP, mastering AES67 interoperability becomes an essential skill for any modern audio engineer.