Understanding Ethernet-Based Audio Transport and Its Demands

Audio over Internet Protocol (AoIP) networks have become the backbone of modern live sound reinforcement, broadcast studios, and installation environments. Unlike traditional point-to-point analog or MADI connections, AoIP leverages standard Ethernet infrastructure to carry dozens, hundreds, or even thousands of audio channels over a single cable. This shift brings enormous flexibility in routing, scalability, and system integration, but it also introduces a critical dependency on network reliability. In a theatre production, a sporting event broadcast, or a corporate conference, a lost audio stream due to a switch failure or cable cut can stop a show, embarrass a client, or create safety hazards. Therefore, planning for redundancy and reliability is not optional — it is a core design requirement for any professional AoIP system.

The challenge extends beyond simple connectivity. Real-time audio streams are unforgiving of packet loss, jitter, and latency variation. A single dropped packet can produce an audible pop or click; sustained loss can mute an entire channel. As networks grow in size and complexity, the probability of failure increases. Redundancy must be built into every layer: the physical infrastructure, the network protocol, the switching architecture, and the monitoring systems. This article examines the practical strategies, protocols, and hardware choices that deliver fault-tolerant AoIP networks. We cover topology design, link-level redundancy, network segmentation, Quality of Service (QoS), and the specific role of industry standards such as SMPTE ST 2022-7 and AES67.

The Foundation: AoIP Protocols and Their Redundancy Mechanisms

Different AoIP protocols handle redundancy in distinct ways. Understanding which protocol your system uses — or which you plan to adopt — is the first step toward building a reliable network. The choice of protocol will dictate which redundancy features are available and how they must be configured.

Dante Redundancy

Audinate’s Dante protocol has long offered a dedicated redundant mode. In this configuration, the primary and secondary network interfaces on Dante devices connect to two separate, independent Ethernet networks. The Dante controller sends identical audio packets on both networks simultaneously. If the primary network experiences a failure, the receiving device seamlessly switches to the secondary stream. This approach provides true physical redundancy but doubles network bandwidth usage and requires two complete sets of switches and cabling. Many professionals consider this the gold standard for critical live events. Dante also supports an alternate "switched" redundancy mode that uses a single network with redundant paths managed by the switch, but dedicated dual‑network mode offers the highest level of fault isolation. For large‑scale installations, careful IP address planning is essential to avoid conflicts between the primary and secondary subnets.

AVB / TSN Support

Audio Video Bridging (AVB) and its successor Time-Sensitive Networking (TSN) include stream reservation and redundancy features defined by IEEE 802.1Qca and IEEE 802.1CB. The latter is particularly powerful — it duplicates streams over disjoint paths and performs in‑seamless failover. However, AVB/TSN redundancy requires managed switches that support these standards, and not all AVB-enabled devices implement it. When available, it offers hardware-based failover with sub‑millisecond recovery times. TSN also adds deterministic latency guarantees through gated scheduling, which further enhances reliability for time-critical audio. The ecosystem for TSN in professional audio is still maturing, but it promises tight integration between the network and media layers.

Ravenna and ST 2022-7

Ravenna, an open AoIP standard commonly used in broadcast, supports SMPTE ST 2022-7, a standard that mandates seamless protection switching. Similar to Dante’s redundant mode, the sender transmits duplicate packets over two independent network paths. The receiver detects missing or corrupted packets and switches between streams without any audible glitch. ST 2022-7 is independent of the transport protocol (RTP, AES67) and is widely adopted in broadcast consoles, routers, and codecs. One key advantage of ST 2022-7 is that it can operate over a single network infrastructure if paths are logically separated (e.g., using VLANs and link aggregation), but best practice still calls for physically separate networks. Ravenna also supports multicast management and precise clock synchronization via IEEE 1588 PTP, which are essential for maintaining alignment across redundant streams.

AES67 and SMPTE ST 2110-30

AES67 is a layer‑3 interoperability standard that allows different AoIP systems (Dante, Ravenna, Livewire+, Q‑LAN) to exchange audio. While AES67 itself does not define a redundancy mechanism, it is often used in conjunction with ST 2022-7. SMPTE ST 2110-30, which is the broadcast standard for uncompressed PCM audio over IP, also relies on ST 2022-7 for hitless protection. In practice, any system that uses RTP‑based audio transport can implement ST 2022-7, provided the endpoints support duplicate‑stream reception. Many broadcast‑grade devices now have dual‑stream capability as a standard feature.

Network Architecture for Maximum Uptime

No matter which protocol you choose, the physical and logical design of your network determines how well redundancy performs. The following architectural elements are essential for building a reliable AoIP network.

Use a Redundant Star or Spine‑Leaf Topology

For most AoIP installations, a redundant star topology is recommended. Each audio endpoint connects to two separate switches (primary and secondary), and those switches are linked via separate fiber or copper uplinks. If any single switch, cable, or port fails, traffic automatically reroutes through the alternate path. This approach requires twice the switch ports and cabling but provides deterministic failover and simple troubleshooting. For larger systems spanning multiple rooms or buildings, a spine‑leaf architecture can scale redundancy without adding excessive latency. In a spine‑leaf design, every leaf switch connects to every spine switch, forming a full‑mesh underlay. This topology provides multiple equal‑cost paths and eliminates the need for spanning tree protocols, which can introduce convergence delays.

Ring topologies can also be used, especially in distributed installs (e.g., stadium concourses, theme parks). With Rapid Spanning Tree Protocol (RSTP) or Media Redundancy Protocol (MRP), a ring can recover from a single break in under 50 ms. However, ring recovery times may be too slow for some uncompressed audio streams (especially when multiple devices are daisy‑chained), and they generally lack the dual‑path duplication that protocols like Dante redundant mode or ST 2022-7 provide. If you choose a ring, ensure all switches support fast convergence and that the ring is not overloaded with bandwidth‑heavy traffic.

Segregate Audio Traffic with VLANs

Virtual LANs (VLANs) allow you to isolate audio traffic from control, video, and general IT data on the same physical infrastructure. This segmentation reduces the risk of broadcast storms, limits unnecessary traffic on audio‑critical segments, and simplifies QoS configuration. A best practice is to create at least three VLANs: one for AoIP media, one for device control (e.g., Dante Controller, WebGUI, PTP), and one for general IT. Trunk ports should carry only the required VLANs to prevent leakage. For redundant networks using dual‑path topologies, assign separate VLANs for primary and secondary audio streams to keep them logically isolated as well. Use 802.1Q trunking with explicit allowed VLAN lists on inter‑switch links.

Implement Quality of Service (QoS)

Ethernet switches are designed to handle multiple traffic types, but without proper QoS, a large file download or video stream can congest a link and cause dropped audio packets. For AoIP, you must classify audio as the highest priority traffic. Typically this means marking audio packets with Differentiated Services Code Point (DSCP) values that map to strict priority queues on the switch. For example, Dante recommends DSCP 46 (Expedited Forwarding) for audio, while AES67 uses DSCP 34 (Assured Forwarding 41). Ensure that all switches in the path honor these marks and that the queue scheduling is set to strict priority rather than weighted fair queuing. Also, configure trust boundaries at the ingress port so that devices cannot overwrite the DSCP markings. Voice VLANs can further simplify QoS by automatically tagging audio traffic from endpoints that support LLDP‑MED.

Quality of Service and Traffic Prioritization

While QoS was mentioned in the previous section, it deserves deeper treatment because misconfiguration is one of the leading causes of audio dropouts in AoIP networks. Packet prioritization must be consistent from the source device all the way through the switching fabric. Use the following guidelines:

  • Classify and mark traffic as close to the source as possible. Endpoints that support DSCP marking (e.g., Dante devices, Ravenna interfaces) should be configured to set the correct DSCP value. If the endpoint cannot mark packets, the switch can re‑mark based on an ACL or VLAN.
  • Map DSCP values to hardware queues. On managed switches, assign DSCP 46 and DSCP 34 to the highest priority queue (queue 4 or 7 depending on switch architecture). Avoid using the default best‑effort queue for any audio traffic.
  • Enable strict priority scheduling. Weighted fair queuing can starve high‑priority streams when low‑priority traffic bursts exceed the queue depth. Strict priority ensures that audio packets are always forwarded first, even if it means dropping lower‑priority data.
  • Set appropriate queue limits. Oversized buffers can add latency; undersized buffers can cause tail drops. Use the switch manufacturer’s recommendations for audio traffic – often a smaller buffer with WRED (Weighted Random Early Detection) disabled or set very high thresholds.
  • Monitor for DSCP remarking. Some switches have default policies that re‑mark assigned DSCP values. Verify that your configuration is not accidentally degrading audio packet priority.

For networks carrying both AES67 and legacy Dante traffic, you may need to reconcile different DSCP values. Both protocols can coexist if the switch maps both DSCP 34 and DSCP 46 to the same high‑priority queue. Some manufacturers provide specific configuration templates for mixed‑protocol environments.

Redundancy at the Endpoint Level

Network infrastructure redundancy only protects against failures in the network itself. Endpoints — consoles, stageboxes, codecs, amplifiers — must also be designed for high availability. Consider the following endpoint‑level strategies:

  • Dual redundant network interfaces. As discussed, Dante and Ravenna devices with dual ports can be connected to separate networks. Ensure the device is configured for redundant mode (not just a passive backup). Test that the failover is hitless before deploying in production.
  • Redundant internal power supplies. Many professional AoIP devices offer dual AC mains inputs. Connect each to a separate UPS and power circuit. If the device only has one power supply, consider using a field‑redundant power injector or an external power switch with dual feeds.
  • GNSS/GPS clock synchronization. For systems that rely on IEEE 1588 PTP (Precision Time Protocol), a grandmaster clock with GNSS reception provides a fallback if the network‑based clock source fails. Multiple grandmasters in a hot‑standby configuration can switch without disrupting audio alignment.
  • Device‑level stream redundancy. Some broadcast consoles can source audio from both a primary and secondary stream simultaneously, using a seamless mixer crossfade if one stream drops. This is akin to N+1 redundancy at the receiver.

Endpoint redundancy often requires additional configuration and careful resource management (e.g., available CPU for duplicate stream processing). Always verify the manufacturer’s specifications for maximum redundant streams per device.

Hardware Selection: Switches, Cables, and Power

Not all Ethernet switches are suitable for AoIP. Consumer‑grade switches lack the necessary buffers, QoS capabilities, and management features. For professional audio, choose managed gigabit switches with the following characteristics:

  • Full Gigabit Ports: Even if your current device uses 100 Mb, future‑proof with 1 Gb or 10 Gb uplinks. Many AoIP – capable devices now ship with 1GbE ports as standard.
  • Low Latency and Jitter: Look for switches with store‑and‑forward latency under 10 µs and low jitter buffers. Cut‑through switching can reduce latency further but may forward corrupted frames; in AoIP environments, store‑and‑forward is generally preferred for error checking.
  • Support for RSTP/MSTP: For ring topologies, RSTP recovery times should be below 50 ms. MSTP (Multiple Spanning Tree Protocol) allows per‑VLAN load balancing in multi‑redundancy scenarios.
  • Link Aggregation (LACP): Allows bonding multiple ports for higher bandwidth and redundancy between switches. LACP also provides active/standby fallback if one link in a bundle fails.
  • PoE+ (if needed): Power over Ethernet simplifies installation for microphones, intercoms, and wall plates. Use switches that can deliver at least 30W per port (PoE+) and have sufficient power budget for all connected devices.
  • IGMP Snooping: For multicast‑based AoIP (common in AES67, Dante multicast, and Ravenna), IGMP snooping prevents audio traffic from flooding all ports. Ensure the switch supports IGMPv3 and fast leave.

For cabling, use at least Cat6 or Cat6a shielded cable to minimize electromagnetic interference, especially in close proximity to audio cables. In long‑run or high‑EMI environments, single‑mode or multimode fiber is superior because it is immune to ground loops and RFI. Always deploy dual‑fiber paths to separate primary and secondary networks. Use appropriate connectors (LC for fiber, shielded RJ45 for copper) and test every link with a cable certifier.

Power Supply Redundancy

A network with dual switches is worthless if a single power outage takes down the entire rack. Use an uninterruptible power supply (UPS) for each switch and, if possible, deploy switches with dual internal power supplies connected to separate UPS units. For critical broadcasts, consider a generator backup in addition to battery backup. Monitor UPS health via SNMP and set up alerts for low battery or over‑load conditions. For remote or unmanned installations, add a network‑controlled PDU that can cycle power to a locked‑up device.

Testing and Monitoring for Continued Reliability

Building a redundant network is only half the battle; maintaining it requires ongoing testing and monitoring. Without regular validation, redundant paths can develop silent failures — a broken fiber that the primary still covers, or a switch that fails to forward duplicate streams. Implement the following practices:

  • Regular Failover Tests: Schedule monthly or quarterly tests where you physically unplug primary cables or power down primary switches. Verify that all audio streams transition to the backup path without audible glitches and that the system recovers automatically when the primary is restored. Document the test results and any deviations.
  • Network Monitoring: Use software such as Audinate Dante Controller (for Dante networks), Lawo RAVENNA Tools, Wireshark, or professional network monitoring platforms (e.g., PRTG, SolarWinds, Zabbix) to track switch CPU loads, port errors, bandwidth utilization, and PTP clock offsets. Set up alerts for unusual packet loss, high latency, or link state changes.
  • Firmware and Software Updates: Keep switch firmware, device drivers, and controller software up to date. Many device failures stem from known bugs that have been patched. Always test updates in a non‑production environment first. Maintain a rollback plan and backup configuration files.
  • Document Everything: Maintain a network documentation binder or digital repository with topology diagrams, static IP assignments, VLAN mappings, QoS settings, switch configurations, and manufacturer contact information. In an emergency, quick access to this documentation can reduce troubleshooting time from hours to minutes. Use version control for configuration files.
  • SNMP and Syslog Monitoring: Configure all managed switches and endpoints to send SNMP traps and syslog messages to a central log collector. Monitor for “Interface up/down” events, spanning tree topology changes, and PTP sync loss. Correlate these logs with audio stream status to identify root causes.

For broadcast facilities, perform a “dark studio” test at least once a year: simulate a complete power and network failure and measure how quickly the system comes back online. This exercise often reveals overlooked single points of failure, such as a single power strip feeding both switch rows or a missing fallback clock source.

Common Pitfalls and How to Avoid Them

Even experienced integrators make mistakes when designing AoIP networks. Here are the most frequent pitfalls and how to steer clear:

  • Using Unmanaged Switches: They cannot enforce QoS, VLANs, or link aggregation. Avoid them entirely. Even for small installations, a basic managed switch is worth the cost.
  • Mixing Redundant Networks on the Same Switch: If primary and secondary streams travel through the same physical switch, a single switch failure takes out both paths. Always use separate switch hardware for primary and secondary networks when using dual‑path redundancy.
  • Forgetting the Control Network: Many AoIP devices require a separate control network or at least a control VLAN. If the control traffic shares the same VLAN as audio, a misconfigured control packet storm can disrupt audio. Isolate control traffic using VLANs or a separate physical network.
  • Ignoring Latency Budgets: Every switch adds a few microseconds of latency. For live sound monitor mixes, total network latency should stay below 1 ms. Ensure your switch count and buffer settings respect the target. Consider using cut‑through switches in latency‑critical paths if error checking is less important.
  • Overlooking Cable Management: Poorly labeled or tangled cables make troubleshooting a nightmare. Use colour‑coded patch panels (e.g., green for primary audio, blue for secondary, yellow for control) and label both ends. Always test cables with a certifier before deployment.
  • Neglecting Multicast Management: Multicast streams can flood every port if IGMP snooping is not enabled, causing switch overload and audio dropouts. Configure IGMP snooping and set up a dedicated querier on the audio VLAN.
  • Assuming PTP Will Work Out of the Box: PTP requires careful clock hierarchy and boundary clock configuration. Incorrect PTP settings can cause timing jitter, leading to packet misordering and dropouts. Always measure clock offset and jitter with a PTP monitoring tool.

Real‑World Example: A Broadcast Truck Deployment

Consider a mobile broadcast unit covering a national sports event. The truck integrates a Lawo console (Ravenna / AES67), multiple audio breakouts, intercom, and a replay system. The network architect deploys two independent Cisco Catalyst switches — one designated primary, the other secondary — each powered by separate UPS units. All Ravenna devices are configured to send dual streams via ST 2022-7. The switches are connected via separate fiber paths running to the truck’s patch bay, using redundant transceivers. QoS is configured to prioritize AES67 audio (DSCP 34) above all else. A network engineer sits in the truck monitoring all streams using a dedicated laptop running Ravenna’s diagnostic tool. During the event, a stage‑hand accidentally kicks the primary fiber patch cable, causing a cut. The secondary network picks up the stream within microseconds, and the on‑air talent never notices. The production continues flawlessly.

This scenario underscores why redundancy must be designed from the ground up — not as an afterthought. The same principles apply to a fixed installation such as a performing arts centre or a corporate headquarters: dual switches, dual cabling, and protocol‑level hitless protection are the blueprint for reliability.

Conclusion: Building Networks That Never Miss a Beat

Reliability in AoIP networks demands more than simply buying “good” switches. It requires a deep understanding of your chosen protocol’s redundancy features, a network topology that eliminates single points of failure, meticulous QoS and VLAN configuration, and a commitment to ongoing testing. For live sound and broadcast professionals, the upfront investment in dual‑redundant networks, managed hardware, and staff training pays for itself the first time a cable fails — and the audience never hears a glitch. By following the practices outlined in this article, you can build AoIP systems that deliver the same reliability as the analog world while embracing the flexibility that digital networking provides.

For further reading, consult the Audinate white papers on Dante redundancy, the Audio Engineering Society’s standards for network audio, the Belden guide to AoIP cabling best practices, and the IEEE paper on TSN stream redundancy.