Understanding Audio over IP: AVB vs AES67

Modern studios are rapidly migrating from traditional point-to-point analog or digital audio wiring to network-based Audio over IP (AoIP) systems. This shift brings significant flexibility, scalability, and cost savings, but it also presents a critical choice: which protocol should anchor your studio's infrastructure? Two of the most prominent contenders are AVB (Audio Video Bridging, now often called TSN – Time-Sensitive Networking) and AES67. While both deliver uncompressed, digital audio over standard Ethernet, they approach the problem from different angles, and their suitability depends heavily on your studio's priorities, existing gear, and operational requirements. This expanded guide compares AVB and AES67 in depth, covering technical fundamentals, latency characteristics, hardware requirements, interoperability, and real-world deployment scenarios, so you can make an informed decision.

What is AVB (Audio Video Bridging / TSN)?

AVB is a set of IEEE standards (802.1Qat, 802.1Qav, 802.1AS, and later 802.1Qbv, 802.1Qbu, etc., collectively known as Time-Sensitive Networking) designed from the ground up to guarantee deterministic, low-latency delivery of time-critical media streams. It was developed by the IEEE Audio Video Bridging Task Group with input from pro audio manufacturers and broadcasters. AVB ensures that audio and video data arrive at the destination with bounded jitter and latency, typically below 2 milliseconds for a single hop.

The key technical components of AVB include:

  • Stream Reservation Protocol (SRP): Switches and endpoints reserve bandwidth in advance for each stream, preventing congestion and packet loss. The network admits streams only if resources are available.
  • Precise Timing (IEEE 802.1AS): A grandmaster clock distributes time across the network, synchronizing all AVB devices to within sub-microsecond accuracy. This enables sample-accurate alignment between multiple channels and devices.
  • Credit-Based Shaper (IEEE 802.1Qav): AVB endpoints and switches use a traffic shaping algorithm to smooth out bursts and minimize jitter, ensuring consistent latency.
  • Low-Latency Forwarding: With TSN extensions like frame preemption (802.1Qbu) and scheduled traffic (802.1Qbv), AVB can achieve worst-case latency as low as tens of microseconds, suitable for IEM (in-ear monitor) mixes and live broadcast workflows.

AVB requires compliant network switches. Standard consumer-grade switches do not support SRP or the credit-based shaper. Popular AVB-enabled switch vendors include Cisco (Catalyst 9000 series), Netgear (M4300, M4500), Extreme Networks, and some managed switches from MikroTik (with ROSv7 TSN support). AVB also requires compatible endpoints, such as MOTU interfaces, Focusrite RedNet, Avid MTRX, and many others from manufacturers like Yamaha (CL/QL consoles), Audio-Technica, and Audinate (Dante AVB).

AVB is heavily used in live sound reinforcement, broadcast trucks, and studios that demand ultra-low latency for real-time monitoring. The trade-off: its strict hardware requirements and less universal interoperability compared to AES67.

What is AES67?

AES67, developed by the Audio Engineering Society and published in 2013 (updated in 2015 and 2018), is not a full transport protocol but rather an interoperability standard that sits atop existing Layer 3 IP transport (RTP/UDP). It defines a common set of parameters that allows different AoIP ecosystems (Dante, Ravenna, Q-LAN, Livewire+, etc.) to exchange audio streams without requiring a single vendor lock-in. AES67 is fundamentally about bridging ecosystems.

Core specifications of AES67 include:

  • RTP (Real-time Transport Protocol): Audio is packetized as RTP over UDP/IP, allowing it to traverse standard IP networks, including VLANs and routed networks.
  • Media Clock: AES67 uses PTPv2 (IEEE 1588-2008) with a profile similar to SMPTE ST 2059-2, enabling synchronization across devices that may use different internal clocks.
  • Session Description Protocol (SDP): Stream discovery and connection parameters (IP addresses, ports, codec, sample rate) are exchanged via SDP files, often handled by control software (e.g., Dante Controller, Ravenna Manager).
  • Codec and Formats: AES67 mandates support for 24-bit PCM at 48 kHz or 96 kHz sample rates, with packet intervals of 1 ms (minimum) or 125 µs (optional).
  • Latency: AES67 does not guarantee a fixed low latency. Practical network latency depends on switch buffering, queue depths, and hop count. Typical one-way latency is 1-10 ms, with higher hops increasing jitter.

One of AES67's greatest strengths is that it runs on standard, managed Gigabit Ethernet switches. You do not need specialized AVB hardware. However, for reliable operation with low jitter, the network must be properly configured with PTP timing, IGMP snooping (for multicast), and possibly DiffServ QoS. AES67 is widely adopted in broadcast (Axon, Lawo), post-production (Dolby, Genelec), and corporate AV environments. It is also the foundation for the SMPTE ST 2110 suite for professional video over IP.

Comparative Analysis: AVB vs AES67 in Detail

Latency and Synchronization

Latency is often the deciding factor. AVB, with its hardware-based stream reservation and traffic shaping, can achieve end-to-end latency of less than 1 ms even over multiple hops, making it suitable for live sound monitor mixing where sub-millisecond response is critical. AES67, while capable of low latency (typically 1-4 ms in a well-managed single-switch environment), introduces more variability and is generally not recommended for extreme real-time applications. For studio tracking and overdubbing, AES67 latency is usually imperceptible, but for foldback or broadcast IFB, AVB wins.

Hardware Requirements

AVB requires network switches that support TSN features (SRP, credit-based shaper, 802.1AS). These switches are more expensive and less common. AES67 works with any managed Gigabit switch that supports IGMP snooping, PTP (Boundary Clock or Transparent Clock optional), and QoS (DSCP). Many professional AoIP devices support both AVB and AES67, but pure AVB paths are rarer. Example: a Dante network uses Dante's proprietary protocol but can also output AES67 streams; it cannot output native AVB without additional bridging.

Interoperability

AES67's primary design goal is interoperability. A Ravenna source can send AES67 to a Dante receiver, or a Q-LAN console to a Livewire+ node. AVB, while standardized, has limited cross-vendor support because not all manufacturers implement the full TSN stack in the same way or in the same network segments. Moreover, AVB is typically limited to single-switch domains (though TSN now allows multi-hop, it's less common). AES67 can traverse routed networks, making it easier to scale across large facilities.

Stream Management and Discovery

AVB uses SRP for automatic stream advertisement and reservation. This is elegant but requires all switches to participate. AES67 relies on vendor-specific control software (e.g., Dante Controller, Ravenna Assistant, Merging's Anubis) or manual SDP configuration. Some newer implementations use RTSP or NMOS for discovery, but it's not inherent. For large-scale deployments with many streams, AES67's richer ecosystem tools can be more powerful.

Cost

AVB switches can cost 2-5x more than standard managed switches. However, AVB endpoints are sometimes simpler because synchronization is handled by the network. AES67 uses standard switches, which are cheaper, but requires more careful network engineering and often additional PTP grandmaster clocks. Total cost of ownership depends on scale and vendor lock-in.

Key Factors for Choosing Your Studio Protocol

No single protocol is universally superior. Consider your studio's specific workflows:

  • Live Sound / Broadcast with Critical Monitoring: If you need sub-2ms round-trip latency for IEMs or broadcast IFB, AVB (TSN) is the clear choice. Ensure your console, IEM transmitters, and converters all support AVB.
  • Post-Production / Music Recording: For tracking rooms where latency below 10ms is acceptable, AES67 is more flexible. You can mix Dante, Ravenna, and other AES67-compatible devices without switching at low cost.
  • Multi-Vendor Environment: If you have or plan to acquire gear from different manufacturers (e.g., Yamaha console, Focusrite converters, Genelec monitors), AES67 is practically mandatory for seamless integration.
  • Network Scale: For a single room or small facility, either works. But if you need to extend audio across a campus or multiple buildings with routing, AES67's Layer 3 compatibility is a major advantage.
  • Future-Proofing: AVB is evolving into TSN, which is gaining traction in industrial automation and automotive. Broadcast and pro audio are increasingly adopting AES67 as the bridge to SMPTE ST 2110, which is becoming the standard for IP-based video. If you anticipate moving into ST 2110, AES67 is the foundation.

Hybrid Approaches: Using Both AVB and AES67

Many modern audio interfaces and consoles support both protocols. For example, the Avid MTRX II can accept AVB streams for low-latency monitoring and simultaneously output AES67 streams to a Dante network. Similarly, some Yamaha consoles have both AVB and Dante/AES67 cards. This allows you to design a hybrid architecture: use AVB for critical real-time paths (e.g., mic preamps to console, console to monitor mixes) and bridge to AES67 for routing to recording software, broadcast feeds, or remote locations. The key is to have a common PTP timing domain and proper network segmentation.

Setting Up Your AoIP Network: Best Practices

Dedicated Switches

Whether you choose AVB or AES67, use a dedicated audio network separate from general data (IT) traffic. This avoids congestion and simplifies QoS settings. For AVB, use TSN-enabled switches; for AES67, any managed Gigabit switch with IGMP snooping and PTP support.

PTP Timing

Both protocols rely on PTP. In AVB, 802.1AS provides grandmaster clocking. In AES67, you need a PTPv2 grandmaster (often integrated into a switch or a dedicated device like a PTP Grandmaster). Ensure all devices are in the same PTP domain and follow the correct profile (default AES67 profile or SMPTE 2059-2). Poor clock synchronization leads to clicks, pops, and drift.

Network Topology

Avoid cascading more than 3-4 switches for AES67 to keep latency and jitter predictable. For AVB, follow manufacturer guidelines; most AVB systems support 7 hops but with cumulative latency. Use link aggregation or 10GbE uplinks if you have many high-channel-count streams.

Quality of Service (QoS)

For AES67, mark audio RTP packets with DSCP EF (46) or CS4 (32) and ensure switches prioritize them over data. AVB handles QoS through SRP automatically, but you must still avoid mixing non-AVB traffic on the same VLAN.

External Resources for Further Learning

Conclusion

AVB and AES67 are both excellent Audio over IP protocols, but they serve different niches. AVB excels in ultra-low-latency, deterministic environments where hardware infrastructure is dedicated and controlled. AES67 shines in interoperability, scalability, and cost-effectiveness across multi-vendor systems. For most professional studios today, a hybrid approach leveraging the strengths of both is the most practical path: use AVB within critical real-time zones and AES67 for bridging to the rest of the facility and the outside world. Assess your current gear, latency tolerance, budget, and future expansion plans before committing. With careful network design, either protocol can deliver high-quality, reliable digital audio that modern studios depend on.