Introduction: Why the Audio Protocol Matters in Modern Broadcast

In today’s broadcast facility, audio is no longer a simple analog signal flowing through dedicated copper lines. It is a digital stream traversing standard Ethernet networks, and the protocol that governs its transport is as fundamental as the acoustics of your control room. The wrong protocol can introduce unacceptable latency, cause clocking conflicts, lock you into a single vendor, or require a complete network overhaul when you need to scale. The right protocol, on the other hand, delivers pristine quality, sub-millisecond timing, and the flexibility to integrate with video, intercom, and production tools over a unified IP infrastructure.

This decision is not just technical—it is strategic. Whether you are building a green-field station, retrofitting an existing plant, or planning a phased migration from a legacy MADI or analog system, your protocol choice will affect every piece of gear you purchase, every network switch you configure, and every engineer you train. Broadcasters today face increasing pressure to support remote production, hybrid workflows, and UHD video over IP. The audio protocol you select must align with these broader operational goals. This article provides a practical, in-depth guide to the key factors, the leading protocols, and the decision framework that will help you choose wisely.

Understanding Audio-over-IP (AoIP) Protocols

Audio protocols are standardized methods for encoding, packetizing, and transporting digital audio over Internet Protocol (IP) networks. They define how audio samples are formatted, how timing is maintained (clocking), how devices discover each other, and how streams are routed. Unlike legacy point-to-point connections, AoIP allows any device on the network to access any audio stream, dramatically simplifying cabling, patching, and reconfiguration.

Broadcast facilities have unique requirements: deterministic low latency, high reliability, support for large channel counts, and interoperability with production and transmission systems. The most common protocols today are AES67, Ravenna, Dante, and Livewire. Each is built on similar principles (RTP, PTP) but differs in implementation, ecosystem, and features. Understanding these differences is critical because your facility may need to support multiple protocols simultaneously during a migration or in a multi-vendor environment.

Beyond the core protocols, many facilities also encounter MADI (Multichannel Audio Digital Interface) in legacy installations. While MADI is a point-to-point serial format rather than an IP-based protocol, it remains common for connecting older consoles, routers, and recording devices. Planning a conversion path from MADI to a native AoIP protocol is a frequent consideration during facility upgrades.

AES67: The Universal Interoperability Standard

AES67 is an open standard published by the Audio Engineering Society (AES). It is not a full protocol stack but a set of specifications that ensure interoperability between different AoIP systems. It defines mandatory support for PCM audio, specific sampling rates (48 kHz, 96 kHz), and the use of Precision Time Protocol (PTPv2) for synchronization. Any device that claims AES67 compliance can send and receive audio with another AES67-compliant device, regardless of the underlying vendor protocol.

For facilities that already have a mix of Dante, Ravenna, or Livewire gear, AES67 acts as a bridge. It is also the basis for SMPTE ST 2110-30, the standard for professional broadcast media over IP. However, AES67 alone does not provide discovery, connection management, or multicast routing configuration—those are handled by the native protocol of each device. This means that while AES67 guarantees basic transport compatibility, the user experience often requires additional software or manual configuration. In practice, you may need to set up multicast addresses manually for each stream or use a third-party routing manager to handle cross-protocol connections.

The AES67 standard has evolved. The AES67-2022 revision introduced support for 96 kHz sampling rates, improved PTP profiles for better stability over wide-area networks, and clarified redundancy requirements. This makes AES67 increasingly viable as a primary protocol for larger facilities, not just a bridging tool. For a facility that values long-term flexibility and vendor independence, building on AES67 as the common transport layer is a sound strategy.

Key strengths: Open standard, vendor-neutral, future-proof for broadcast IP ecosystems, no per-port licensing fees. Considerations: No built-in device discovery; requires careful network planning for PTP and multicast; may require additional management software.

Learn more on the AES standards page.

Dante: The Ease-of-Use Leader

Dante, developed by Audinate, is the most widely deployed AoIP protocol in the pro-audio and broadcast world. Its main advantage is simplicity: Dante-enabled devices automatically discover each other on the network, and audio routing is managed through a free software application (Dante Controller). Latency is configurable from 0.25 ms to 10 ms, making it suitable for live mic feeds and studio monitors alike. The automatic discovery and routing capabilities significantly reduce the time required to set up a new system, which is why Dante is popular in fast-paced production environments.

Dante supports up to 1024 x 1024 audio channels per device with redundant network paths (Dante Redundant), and its clocking is highly robust. The ecosystem is enormous, with hundreds of manufacturers offering Dante cards and built-in interfaces. For broadcast facilities, Dante is often chosen when the primary requirement is quick deployment and a large existing product base. However, there are nuances: the standard Dante system uses a single subnet and does not natively route audio across VLANs without the addition of Dante Domain Manager, which introduces per-subscription costs.

For facilities integrating with video-over-IP workflows, Dante offers the Dante AVIO adapter line and support for AES67 bridging on many newer devices. Audinate also participates in the SMPTE ST 2110 ecosystem, though Dante's native protocol differs from the AES67/RTP model used in ST 2110. This means that bridging between Dante and a full ST 2110 environment may require additional conversion steps or hardware.

Key strengths: Ease of use, automatic discovery, wide product ecosystem, low latency, robust clocking. Considerations: Proprietary licensing adds cost per device (typically $50–$150 per endpoint); not natively compliant with SMPTE ST 2110 without additional bridging; single-subnet limitations without Domain Manager.

Ravenna: High-Performance for Large Installations

Ravenna is an open technology originally developed by ALC Network (now part of the AES67-Ravenna alliance). It emphasizes high channel density, sub-millisecond latency, and redundancy. Ravenna uses standard IEEE 1588 PTPv2 for synchronization and RTP for transport, and it is fully AES67-compatible by default. It is widely adopted in broadcast consoles, routing matrices, and intercom systems from manufacturers like Lawo, DirectOut, Neumann, and Merging Technologies. Ravenna's architecture is designed from the ground up for large-scale installations, making it a popular choice for major broadcast centers and OB (outside broadcast) trucks.

Ravenna’s strength lies in its ability to handle large-scale installations with hundreds of simultaneous streams while maintaining deterministic timing. It supports both unicast and multicast, and offers advanced network redundancy features like seamless switchover using RSTP or proprietary link aggregation. The protocol also supports a wide range of sample rates (up to 192 kHz) and bit depths, making it suitable for high-resolution audio applications beyond standard broadcast. For facilities that plan to integrate with SMPTE ST 2110 video or require future-proofing for 4K/8K production, Ravenna is a strong candidate because it shares the same underlying transport standards (RTP, PTP) as ST 2110.

One practical consideration is that Ravenna deployments typically require more network expertise than Dante. While tools like the Ravenna Web Manager simplify discovery and configuration, the initial setup—especially for multicast routing and PTP hierarchy—demands careful planning. However, once configured, Ravenna systems are extremely stable and scalable. Many facilities running Ravenna report years of trouble-free operation with no clock drift and minimal jitter.

Key strengths: High channel counts, excellent clocking, open standard (royalty-free), strong broadcast vendor support, native ST 2110 alignment. Considerations: Slightly steeper learning curve than Dante; discovery and connection management are more manual; requires quality managed switches with PTP support.

Livewire: Streamlined for Broadcast and Radio

Livewire, developed by Telos Alliance, was one of the first AoIP systems specifically designed for broadcast radio. It uses the Livewire+ protocol, which is built on the same RTP/PTP foundation as AES67. Livewire is known for its tight integration with Telos phone systems, Axia consoles, and other broadcast peripherals. It offers automatic configuration, built-in GPIO over IP, and a simple naming convention for audio channels that aligns with broadcast workflow terminology (e.g., "Studio 1 Mic 1").

Livewire is particularly popular in radio stations and smaller TV facilities where the ecosystem of Telos/Axia equipment is already in use. The latest Livewire+ implementations are AES67-compliant, allowing them to talk to other protocols on the network. This means a Livewire-based facility can integrate Dante devices via AES67 if needed, though the configuration may require manual steps. One distinctive feature of Livewire is its support for "Logic" over IP—GPIO and control signals travel alongside audio streams, simplifying automation and tally systems.

However, the device ecosystem outside the Telos world is more limited than Dante or Ravenna. If you choose Livewire, you are making a strategic commitment to the Telos Alliance ecosystem for consoles, phone systems, and peripherals. This can be a benefit if you already use Telos gear, but it limits flexibility if you later want to incorporate third-party devices that lack Livewire-native support. Livewire is best suited for facilities where broadcast workflow integration and simplicity are the top priorities, and where the entire audio chain can be standardized around Telos products.

Key strengths: Simple setup, integrated broadcast workflow tools, built-in GPIO over IP, AES67 compliance in recent versions. Considerations: Best suited when committed to Telos/Axia gear; less vendor diversity; smaller ecosystem for third-party devices.

Critical Decision Factors

Beyond protocol features, your choice must align with your facility’s operational reality. Here are the factors that matter most in a broadcast context.

Compatibility and Interoperability

No facility is an island. You need to exchange audio with production studios, remote trucks, streaming encoders, and transmission plants. If your chosen protocol is not AES67-capable, you may face costly gateways or format converters. Look for devices that natively support AES67 or SMPTE ST 2110-30. Also consider future integration with video-over-IP (SMPTE ST 2110), which typically requires AES67 for the audio essence. For instance, if you plan to connect to a centralized router that handles both video and audio, ensuring that your audio protocol uses the same PTP domain as your video infrastructure is essential to avoid clocking mismatches.

In multi-protocol environments, plan for a gateway strategy. Some manufacturers offer hardware bridges (e.g., DirectOut's CONVERTER series) that translate between Dante, Ravenna, MADI, and AES67 in real time. Software-based solutions exist as well, but they may introduce latency or processing overhead. The key is to evaluate not just whether two protocols can coexist, but how cleanly and reliably they interoperate under broadcast loads.

Latency Requirements

For live broadcast, latency under 1 millisecond is often required for foldback, intercom, and microphone monitoring. Dante and Ravenna can achieve 125 microseconds at the lowest buffer settings, while AES67 implementations typically run at 1 ms or higher. Test the actual latency with your network hardware. Also consider the cumulative latency across multiple hops: if you are linking facilities over a WAN, you may need to factor in network propagation delays. In a distributed facility with several buildings, the total end-to-end latency could climb to 3–5 ms even with low-latency protocols.

Some protocols allow you to trade off latency against network robustness. A smaller buffer reduces latency but increases the risk of dropouts from network jitter. In a well-designed network with managed switches and dedicated QoS, you can safely operate at the lowest buffer settings. If your network infrastructure is less controlled or includes wireless links, a slightly higher buffer setting (e.g., 2 ms) may be safer. Plan to validate your latency budget with a test signal and an oscilloscope or phase meter before commissioning the system.

Network Infrastructure and Bandwidth

Broadcast AoIP typically uses multicast for efficient distribution. This requires IGMP snooping enabled on your managed Ethernet switches, as well as a robust PTP boundary clock or ordinary clock hierarchy. Unmanaged switches are not suitable. Bandwidth is rarely an issue: a single uncompressed 48 kHz/24-bit stereo channel uses about 2.3 Mbps. Even a 128-channel system is well under 1 Gbps. However, you must plan for redundant networks (primary and secondary) to survive a switch failure without losing audio. This means doubling your switch infrastructure and cabling, which can be a significant cost in large facilities.

Network switches for AoIP should have high-quality clock oscillators to support PTP transparent clock or boundary clock functionality. Not all managed switches are equal in this regard. Switches from manufacturers like Cisco, Arista, Netgear, and Luminex offer specific models certified for AoIP use. Check the manufacturer's recommended switch list for your chosen protocol. Also plan for link aggregation if you need more than 1 Gbps of throughput—though this is rarely necessary for audio alone, it may be needed if you combine audio with video, control, and file traffic on the same network.

Scalability and Future Growth

Choose a protocol that scales both in channel count and in geographic reach. Ravenna and AES67-based systems can easily grow to thousands of channels across multiple buildings with proper PTP distribution. Dante scales to 1024 channels per device but can be constrained by the single-domain concept; Dante Domain Manager allows scaling across VLANs and sites but adds cost. Livewire is more suited to a single facility or campus of moderate size. For facilities with multiple buildings or remote studios, investigate whether the protocol supports wide-area operation over IP links with acceptable latency and reliability.

Consider also the scalability of your support team. A protocol that is widely used in your region or by your staff engineers may be easier to maintain and troubleshoot than a less common one. Factor in the availability of training, certification programs, and third-party support. For example, Dante offers certification levels from Associate to Expert, which can be valuable for staff development.

Cost of Ownership

Licensing fees are baked into the hardware cost. Dante has a per-port royalty that often adds $50–$150 per endpoint. Ravenna and AES67 are royalty-free, so their hardware may be cheaper, but you pay for advanced network switches and possibly for software management tools. Factor in training costs: engineers familiar with one protocol may need time to learn another. The total cost of ownership includes a spare parts stock, network maintenance, and any bridging hardware needed for interoperability with legacy systems. In a large facility with hundreds of audio endpoints, the per-port licensing cost of Dante can add up significantly, potentially making Ravenna or AES67-native solutions more cost-effective at scale.

Don't overlook the cost of certification and testing. If your facility requires SMPTE ST 2110 compliance, you may need to pay for formal conformance testing on your devices and network. This is more common in large broadcast centers and network operations hubs. Budget accordingly for test equipment, consultants, and validation services.

Practical Network Design Considerations

Implementing AoIP in a broadcast facility is not a plug-and-play exercise. You must design your network to support the specific requirements of the protocol you choose.

Precision Time Protocol (PTP) and Clocking

All AoIP protocols rely on PTPv2 (IEEE 1588-2008) to synchronize sample clocks across all devices. A PTP grandmaster clock (often external GPS-disciplined) provides a master time reference. For facilities with video, you may need to lock audio PTP to the video reference (such as genlock) to avoid drifting during production. Ensure your network switches are PTP-aware (transparent clocks or boundary clocks) to maintain sub-microsecond accuracy across many hops. In a large facility with multiple switch tiers, plan your PTP hierarchy carefully: each switch should be configured as a boundary clock if possible, rather than relying on end-to-end transparent clock mode, which becomes inaccurate over many hops.

Some facilities choose to run separate PTP domains for audio and video to isolate clocking issues. However, this adds complexity and requires careful management at the boundaries. A simpler approach is to use a single grandmaster clock with a PTP profile that supports both audio (IEEE 1588 profile for AES67) and video (SMPTE ST 2059-2). Many modern grandmaster clocks can output multiple profiles simultaneously. Test your clock recovery chain thoroughly before putting it into production.

Quality of Service (QoS)

Audio packets must be prioritized over data traffic to avoid jitter and packet loss. Configure DSCP marking on switches: typically DSCP 46 (Expedited Forwarding) for audio streams. Set strict-priority queues and limit bandwidth usage to prevent congestion. Test your network with a packet generator before connecting real audio gear. In a converged network carrying audio, video, and data, you may need multiple traffic classes: voice/audio (highest priority), streaming video (medium), control data (medium-low), and best-effort data (lowest). Define and enforce these queue policies across all switches.

Also consider the impact of multicast MAC address filtering. Each audio stream uses a multicast MAC address, and switches must learn and forward these efficiently. Enable IGMP snooping and configure a querier for each VLAN carrying multicast audio. Without proper IGMP configuration, switches may flood multicast traffic to all ports, wasting bandwidth and causing packet loss.

Redundancy and Failover

Broadcast cannot afford downtime. Implement a parallel secondary network (separate switches and cables) for the primary audio protocol. Dante’s Redundant mode and Ravenna’s seamless protection switching both require two independent network paths. Plan for automatic switchover in less than one audio frame (typically < 4 ms). Document your network topology and test failover scenarios regularly. In practice, many facilities run primary and secondary networks in an active/standby configuration, with the secondary network fully isolated and tested weekly. Some advanced setups use link aggregation or even LAG with active/active traffic, but this requires careful validation of switch convergence times.

Don't forget power redundancy. Each network switch should have dual power supplies connected to separate UPS feeds. Consider also redundant PTP grandmaster clocks in a hot-standby configuration. The grandmaster clocks should be synchronized via GPS or another common time source to ensure seamless handover if the primary fails.

Future-Proofing with SMPTE ST 2110 and AES67

The trend in broadcast is toward full IP-based production, where video, audio, and data are all carried on the same network using SMPTE ST 2110 standards. Audio in ST 2110 is defined by ST 2110-30 (PCM audio, essentially AES67) and ST 2110-31 (AES3-transport). If you plan to move to IP video in the next few years, selecting an audio protocol that is natively ST 2110-30 compliant will avoid a major re-architecture. Both Ravenna and Dante (with Dante AVIO or Dante Domain Manager) can integrate, but Ravenna is more directly aligned with ST 2110 as it uses the same underlying standards and PTP profiles.

For radio-only facilities, ST 2110 may be less relevant, but AES67 remains the interoperability backbone. The AES67-2022 revision added support for 96 kHz and improved PTP profiles, making it even more robust. Even if you are not moving to video-over-IP today, choosing an AES67-capable protocol preserves your options for future collaboration with video production teams, remote trucks, and cloud-based workflows. The broadcast industry is steadily converging on IP standards, and a facility that invests in AES67 compliance today will have fewer compatibility hurdles tomorrow.

Another emerging trend is cloud-based audio processing. Several vendors now offer virtualized audio routers and processing engines that run on standard server hardware and connect to the facility via AoIP. These systems typically rely on AES67 or ST 2110-30 to interface with physical gear. If you anticipate moving some processing (mixing, routing, encoding) to the cloud, ensure your chosen audio protocol can bridge to a cloud environment with low latency and support for network timing over the WAN.

Case Study: Choosing a Protocol for a Mid-Size TV News Facility

Consider a facility with 6 control rooms, 4 studios, and a central machine room. They plan to replace an old analog router with AoIP. The facility already has a console from a Ravenna-supporting manufacturer (Lawo), but also uses wireless mic receivers with Dante outputs. After analysis, the engineering team chooses Ravenna as the backbone because it is AES67-compliant and allows the Dante devices to connect via AES67 bridging. They install a PTP grandmaster clock and manage multicast routing through a central software controller. The result is a single IP infrastructure for all audio, with room to add 2110 video in the future.

The key lesson from this case study is to choose a protocol that connects your existing islands rather than forcing a single-vendor ecosystem. The team invested in a gateway (DirectOut EXBOX.MD) to convert Dante streams to AES67 for the Ravenna network. This added some cost and complexity but preserved the existing wireless mic investment. Over time, as Dante devices are replaced, the team may transition to Ravenna-native gear, further simplifying the architecture. The facility also implemented a separate management VLAN for all AoIP control traffic, ensuring that routing commands and status updates do not interfere with audio streams.

Step-by-Step Decision Framework

  1. Audit your existing equipment. List every audio device, its current protocol support, and its expected lifespan. Include consoles, microphone receivers, intercom systems, routing matrices, and recording devices. Note which devices have AES67 capability built-in and which require adapters.
  2. Define your latency and channel count requirements. For a live talk show, latency under 1 ms is critical. For radio playback, 2–5 ms may be acceptable. Count your current and near-future channel requirements, factoring in growth for new studios or productions.
  3. Determine your video integration roadmap. If you plan to move to IP video, prioritize AES67/ST 2110 compatibility. If you are staying SDI for the next five years, the protocol choice is less constrained, but you should still consider interoperability with remote production partners who may use IP.
  4. Evaluate your network readiness. Can your switches handle PTP, IGMP, and QoS? Do you have budget for a redundant network? If your network infrastructure is aging, factor in the cost of upgrading to managed switches with PTP boundary clock capability.
  5. Select two or three candidate protocols. Test them in a lab with representative gear before committing. Use a test plan that measures latency, jitter, clock stability, and failover time. Include at least one production audio scenario that mirrors your typical workflow.
  6. Consider vendor lock-in risks. Prefer open standards or protocols with multiple manufacturers. If you choose a proprietary protocol, have a documented migration path to AES67 or ST 2110 if needed later.
  7. Plan for training and support. Ensure your engineering team can maintain the chosen system. Budget for manufacturer training, certification programs, and external consultants if in-house expertise is lacking. Document your network design and workflow procedures thoroughly.

Conclusion

Choosing the right audio protocol for your broadcast facility is a multidimensional decision that balances technical performance, existing equipment, future growth, and budget. There is no universal "best" protocol; rather, the best choice is the one that aligns with your facility's specific workflow and roadmap. AES67 provides the foundation for interoperability across all systems, while Dante offers simplicity, Ravenna provides high-channel-density performance, and Livewire integrates tightly with broadcast consoles. Start by understanding your latency and scalability needs, then evaluate each protocol's ecosystem and network requirements. With careful planning and testing, you can build an audio-over-IP infrastructure that serves your facility reliably for years to come.

The broadcast industry is moving steadily toward full IP production, and audio protocols are the bedrock of that transition. By making an informed, strategic choice today, you position your facility to adapt to new workflows, new partners, and new technologies without costly rework. Invest in your network design, test thoroughly, and train your team—your facility's audio future depends on it.

For further reading, explore the Ravenna Ecosystem and the Audinate Dante technical resources. The SMPTE ST 2110 standards suite is documented at the SMPTE website. For a deeper dive into PTP timing and network design for broadcast, consult the IEEE 802.1AS standard.