The Importance of Network Bandwidth Planning for AES67 Deployments

Professional audio over IP has fundamentally changed how broadcasters, live sound engineers, and production facilities handle audio distribution. Standards like AES67 provide a universal method for high‑quality, low‑latency audio streaming over standard Ethernet networks. Yet the success of any AES67 deployment hinges on rigorous network bandwidth planning. Without it, audio streams become vulnerable to latency spikes, packet loss, and dropouts that can ruin a live broadcast or critical recording session. This expanded guide explains why bandwidth planning matters, how to calculate your needs with precision, which network design choices ensure reliable performance, and how to maintain that performance as your system grows.

Understanding AES67 and Its Bandwidth Consumption

AES67 is a standard published by the Audio Engineering Society (AES) that defines how to transport high‑quality, low‑latency digital audio over IP networks using existing Ethernet infrastructure. It operates at Layer 3 of the OSI model, meaning it can route across subnets and wide‑area networks. AES67 is designed to interoperate with other audio networking protocols such as Dante, RAVENNA, and Livewire, making it a universal bridge for professional audio equipment.

Each AES67 audio stream—often called a flow—consists of digital audio samples packed into IP packets. The bandwidth consumed by a single stream depends on three core parameters: sample rate, bit depth, and the number of channels. For example, a stereo stream at 48 kHz sample rate and 24‑bit depth uses approximately 4 Mbps of network bandwidth. An uncompressed 64‑channel stream at 96 kHz and 24‑bit can exceed 130 Mbps. Understanding these numbers is the first step in realistic bandwidth planning.

The Role of Packetization Overhead

Raw audio data is not the only factor. AES67 uses the Real‑time Transport Protocol (RTP) to encapsulate audio, adding IP, UDP, and RTP headers. The packetization interval—how many samples are packed into each packet—directly affects overhead. A 1 ms interval means more packets per second (and thus more header overhead) than a 4 ms interval. For example, with a 1 ms packetization at 48 kHz, each packet carries 48 samples. With a 4 ms interval, each packet carries 192 samples, reducing the packet rate by a factor of four. The trade‑off: longer intervals increase latency, which may be unacceptable in live sound reinforcement. Network engineers must account for overhead when calculating total bandwidth. A good rule of thumb is to add 10–15% overhead on top of the raw audio data rate, but that percentage can climb to 20% or more with very short packetization intervals.

Bit Rate Calculation Example

To compute the bandwidth of a single AES67 stream:

  • Raw audio data rate = (number of channels × sample rate × bit depth) / 1,000,000 Mbps.
  • Packetized rate = raw data rate × overhead factor. For a 1 ms interval, use 1.15 (15% overhead); for 4 ms, use 1.10.

Consider a 32‑channel stream at 96 kHz, 24‑bit, 4 ms packets: raw rate = 32 × 96000 × 24 = 73,728,000 bits/sec = 73.73 Mbps. With 10% overhead ≈ 81.1 Mbps. That single stream nearly saturates a 100 Mbps link. This illustrates why gigabit infrastructure is often mandatory.

Why Proactive Bandwidth Planning Is Non‑Negotiable

Many audio professionals assume their existing office or production network can handle a few audio streams without issue. That assumption often leads to trouble. In live production and broadcasting environments, multiple streams coexist with data traffic, control signals, video, and other services. Without deliberate bandwidth planning, the network can become congested, causing:

  • Packet loss – Missing audio samples that result in clicks, pops, or silence. A single lost packet can corrupt dozens of samples.
  • Increased latency – Queuing delays in switch buffers introduce jitter, forcing receivers to use larger playout buffers, which increases end‑to‑end latency beyond acceptable limits for live monitoring.
  • Degraded audio quality – Even if packets arrive, excessive jitter forces receivers to drop late packets. The result is audible artifacts, especially during transient‑rich material like percussion or speech.
  • Synchronization failures – AES67 relies on Precision Time Protocol (IEEE 1588 PTP) for clock alignment. When bandwidth is insufficient, PTP messages may be delayed or lost, causing loss of sync across all streams.

Conversely, over‑provisioning bandwidth without understanding actual needs wastes budget on unnecessarily high‑speed switches and fiber links. Proper planning balances cost with performance.

Live Event Case Study

Consider a touring sound company deploying 48 channels of AES67 stage‑to‑FOH, plus 16 channels of intercom, plus control data from a console automation system. If the network switch between stage and FOH is shared with a guest Wi‑Fi access point and file transfers, unplanned video streaming from a director’s tablet can spike traffic above available capacity. The result: dropouts during the headline act. Proactive bandwidth planning, VLAN segregation, and QoS would have prevented this scenario.

Calculating Your Bandwidth Requirements

Before designing the network, calculate the total bandwidth needed for all anticipated AES67 streams. Follow these steps:

  1. Inventory every audio source – List all microphones, playback devices, codecs, mixers, and intercoms that will produce streams. Include both fixed and ad‑hoc sources.
  2. Define stream parameters – For each source, note the number of channels, sample rate (48 kHz, 96 kHz, 192 kHz), bit depth (16, 24, 32), and packetization interval (typically 1 ms or 4 ms).
  3. Calculate per‑stream data rate – Use the formula above, adding the appropriate overhead factor.
  4. Sum all streams – Add the per‑stream rates together for a baseline total.
  5. Add margins – Include at least 20% headroom for traffic bursts and future expansion. In mission‑critical environments, 30–50% headroom is prudent.

Example calculation: A facility with 32 stereo streams (48 kHz, 24‑bit, 1 ms packets) – each stream approx 4.6 Mbps – needs ≈ 147 Mbps. Adding 20% headroom gives ≈ 176 Mbps. This fits easily within a 1 Gbps link, but if that link also carries video or file transfers, QoS becomes essential to protect the audio.

Network Infrastructure Design for AES67 Bandwidth

Bandwidth is only one piece of the puzzle. The network architecture must support the calculated load without introducing bottlenecks. Key design elements include switch selection, cabling, Jumbo Frames, VLANs, and Quality of Service (QoS).

Managed Switches with Sufficient Backplane Bandwidth

Consumer‑grade unmanaged switches lack the buffer memory and forwarding capacity needed for multiple AES67 streams. Use managed switches with a non‑blocking backplane that can handle the aggregate bandwidth of all ports simultaneously. For a 48‑port gigabit switch, this means a switching capacity of at least 96 Gbps (full‑duplex). Also ensure switches support IGMP snooping to efficiently handle multicast streams, which are common in AES67 deployments. Without IGMP snooping, multicast traffic is flooded to all ports, wasting bandwidth and increasing CPU load.

Jumbo Frames for Reduced Overhead

Larger MTU (Maximum Transmission Unit) sizes, such as 9000 bytes (jumbo frames), allow more audio samples per packet. This reduces header overhead and lowers packet‑per‑second rates, easing the load on switch CPUs. For example, using jumbo frames with a 4 ms interval can cut overhead from 15% to under 5%. However, all devices along the path must support jumbo frames consistently. If any device only supports standard 1500‑byte MTU, you must use the smaller size network‑wide. Test compatibility thoroughly before production.

Quality of Service (QoS) Configuration

QoS ensures that AES67 audio packets receive priority over less time‑sensitive traffic (file transfers, web traffic, video). Configure DSCP (Differentiated Services Code Point) markings on audio streams—typically set to EF (Expedited Forwarding, DSCP 46) for low‑latency traffic. On switches, implement strict priority queuing so audio is never delayed by data bursts. A typical configuration: map DSCP EF to queue 3 (highest priority), all other traffic to queue 0 (best effort). Without QoS, a large file download on the same link can cause audio dropouts.

VLAN Segmentation

Separating AES67 traffic onto dedicated VLANs isolates it from other network activity, reducing broadcast traffic and limiting the scope of PTP clock domains. Create an “Audio VLAN” carrying only AES67 streams and PTP messages. Control networks, data networks, and guest Wi‑Fi reside on separate VLANs. Use 802.1Q trunk ports for inter‑switch links. If inter‑VLAN routing is needed (e.g., for control software to reach audio devices), ensure your router or Layer 3 switch provides sufficient throughput and low latency—ideally at least 1 Gbps.

Cat6a or better is recommended for distances up to 100 m at 10 GbE. For longer runs or higher resilience, consider fiber optic with SFP+ modules. When using 1 GbE links, ensure that the aggregate stream bandwidth on any link does not exceed 60–70% of link capacity to accommodate bursts. For high‑density installations, consider 10 GbE uplinks between switches to eliminate choke points.

Redundancy and Failover with SMPTE ST 2022‑7

For mission‑critical applications, a single network path is risky. AES67 can be combined with SMPTE ST 2022‑7 for seamless hitless redundancy. This standard sends duplicate audio streams over two physically separate network paths (or two separate cables). The receiver compares the two streams, selecting the best quality without interruption if one link fails or becomes congested. Redundancy doubles bandwidth usage per stream, so your planning must account for twice the traffic on each path. Many professional AES67 endpoints and switches support this feature natively. Ensure both paths are truly independent (different switches, different cables, even different power sources) to avoid a single point of failure.

Monitoring and Ongoing Bandwidth Management

Bandwidth planning does not end at deployment. Networks evolve: new devices are added, firmware updates change traffic patterns, and unforeseen applications consume bandwidth. Implement network monitoring tools that provide real‑time per‑port utilization, packet loss, and jitter measurements. SNMP‑based systems like PRTG, MRTG, or LibreNMS can alert you when bandwidth on the audio VLAN exceeds 80% of capacity. Regularly review your stream inventory and recalculate bandwidth as part of preventive maintenance.

Tools for Audio‑Specific Monitoring

  • Ravenna or Dante Controller – These tools show active streams, latency, and packet loss per device.
  • Wireshark – Capture RTP streams to analyze jitter, sequence numbers, and PTP timing.
  • iPerf3 – Generate test traffic to verify switch throughput and QoS before a live event.
  • Network Time Protocol (NTP) statistics – Ensure PTP grandmaster clock stability; even small drifts can disrupt multiclient synchronisation.

Common Pitfalls to Avoid

  • Ignoring multicast group management – Too many multicast groups can overwhelm switch forwarding tables (CAM tables). Use IGMP snooping and limit groups per VLAN. Design your stream addressing to minimize the number of groups.
  • Mixing clock domains without proper boundaries – Different PTP profiles (e.g., AES67 vs. SMPTE ST 2059) or multiple grandmaster clocks can cause sync issues. Use boundary clocks or transparent clocks at domain boundaries.
  • Underestimating control traffic – Discovery protocols (mDNS, SAP) and remote control commands also consume bandwidth, especially on large networks. Place them on a separate VLAN or restrict broadcast domains.
  • Not testing under load – Simulate full‑capacity traffic before a live event. Use traffic generators or dedicated rehearsal time to stress the network. Verify that all streams coexist without errors.
  • Assuming all switches are equal – Low‑cost “managed” switches may have shallow buffers, limited IGMP groups, or poor QoS implementation. Choose models from vendors with proven AVoIP support (e.g., Cisco, Netgear M4250, Arista, Luminex).

Future‑Proofing Your AES67 Network

AES67 continues to evolve. Higher sample rates (384 kHz, DSD) and more channels per stream are already appearing in products. Meanwhile, convergence with video (IPMX) and other media transport standards will increase bandwidth demands further. When planning your network, choose switches and cabling that exceed current needs by a comfortable margin. Deploying 10 GbE uplinks between switches today can accommodate years of growth without rip‑and‑replace. Consider using a dedicated management network to offload control traffic from the audio VLAN. Also plan for redundancy from the outset; retrofitting ST 2022‑7 is much harder than designing it in.

Another future‑proofing strategy is to select equipment that supports both AES67 and newer standards like SMPTE ST 2110 (for uncompressed video and audio). While ST 2110 requires even higher bandwidth, the underlying network infrastructure (switches, cabling, QoS) is largely the same. Investing in robust, scalable hardware now saves money and effort later.

Conclusion

Network bandwidth planning is not an optional step for AES67 deployments—it is the foundation of reliable audio‑over‑IP. By calculating realistic stream requirements, designing switches with adequate capacity and QoS, segmenting traffic with VLANs, and implementing proactive monitoring, you can build a network that handles dozens or hundreds of high‑quality audio streams without issues. The effort invested in planning pays off during live broadcasts, critical recordings, and daily operations where every millisecond and every sample counts.

For further technical depth, consult the AES67 standard document itself (AES67‑2018), the RAVENNA network design guide (RAVENNA Design Guide), and the IEEE 802.1Q standard for VLAN and QoS fundamentals (IEEE 802.1Q). For a deeper dive into PTP implementation, see the IEEE 1588 standard (IEEE 1588‑2019). These resources provide the authoritative guidance needed to master AES67 network design.