Introduction: Why Latency Matters in Audio‑over‑IP

Audio‑over‑IP (AoIP) has become the backbone of modern professional audio production, from live concerts and broadcast studios to installed sound systems and remote recording sessions. By transmitting digital audio over standard Ethernet networks, AoIP offers flexibility, scalability, and cost savings compared to traditional analog or digital point‑to‑point connections. However, the very nature of packet‑based networking introduces a persistent challenge: latency. For audio engineers, system integrators, and IT managers, understanding the sources of latency and knowing how to control them is essential to delivering synchronised, glitch‑free audio.

Latency is not simply an annoyance; in real‑time applications it can cause audible echo, comb‑filtering, lip‑sync errors in video, and a disjointed experience for performers and audiences alike. Even a few milliseconds of added delay can ruin a live mix or break the timing of a distributed conference system. This article explores the physics and network engineering behind AoIP latency, dissects the key contributing factors, and provides actionable strategies to minimise delay—enabling you to build AoIP systems that perform reliably under the most demanding conditions.

What Is Latency in Audio‑over‑IP?

Latency is the time it takes for an audio signal to travel from the source’s analogue‑to‑digital converter (ADC), through the network, and out through the destination’s digital‑to‑analogue converter (DAC). In AoIP systems this is often called end‑to‑end latency and is measured in milliseconds (ms). For comparison, a typical human ear can detect delays of around 10–20 ms in a live sound reinforcement setup, while broadcast environments often require latencies below 5 ms to maintain lip‑sync and interactive communication.

It is important to distinguish latency from jitter. Latency is the average delay; jitter is the variation in that delay over time. High jitter forces receivers to use larger receive buffers to reassemble packets correctly, which directly increases overall latency. Therefore, minimising both latency and jitter is a dual objective in AoIP network design.

Latency can be broken into three stages:

  1. Capture latency – time to sample, convert, and packetise audio.
  2. Network transit latency – time spent on wires, switches, and routers.
  3. Playback latency – time to buffer, de‑packetise, and convert back to analogue.

Each stage offers opportunities for optimisation.

Core Factors Contributing to AoIP Latency

Network Bandwidth and Congestion

Audio‑over‑IP streams consume relatively modest bandwidth (e.g., 48 kHz/24‑bit stereo is ~2.3 Mbps), but when dozens or hundreds of channels share a network, cumulative bandwidth can saturate switches. Congestion causes packets to queue in switch buffers, adding variable delays. Managed switches with ample internal buffer capacity and support for Quality of Service (QoS) are critical to keep audio packets moving ahead of less time‑sensitive traffic such as file transfers or video.

Packet Size and Buffering

Every AoIP protocol divides audio into packets. Smaller packets (e.g., 1‑ms audio payload) reduce the time the transmitter spends waiting to fill a packet, lowering capture latency. However, smaller packets increase the number of packets per second, raising overhead and switch processing load. Larger packets (e.g., 4‑ms payload) reduce CPU overhead but introduce higher base latency. Most modern protocols, including Dante, Ravenna, and AES67, allow the user to select packet sizes or “latency modes” to trade off overhead for delay. The optimal setting depends on the network capacity and the application’s tolerance for latency.

Receive buffering also plays a role. A device’s jitter buffer holds incoming packets to smooth out network timing variations. A deep buffer (e.g., 5 ms) guarantees fewer dropouts but adds latency. A shallow buffer (e.g., 1 ms) lowers delay but risks dropouts if the network has jitter. Configuring jitter buffers appropriately for the network’s stability is a balancing act.

Protocol Efficiency and Overhead

Different AoIP protocols have different overhead. Raw audio data must be wrapped in network headers (Ethernet, IP, UDP, RTP) plus any protocol‑specific framing. Protocols like AES67 are based on standard RTP and can be used across vendors, but they may require more careful synchronization. Dante (Audinate) uses a proprietary, highly optimised transport layer with low overhead and tight timing, often achieving sub‑1 ms latencies on dedicated networks. Ravenna (ALC Network) also delivers very low latency, typically 1–2 ms, and supports IEEE 1588 (PTP) for clock synchronization. The choice of protocol influences the minimum achievable latency, the complexity of network configuration, and the range of supported hardware.

For further details on protocol differences, refer to the AES standards page for AES67 and the Dante FAQ.

Clock Synchronisation and Timing Drift

All AoIP systems rely on a shared clock to keep sample rates aligned across devices. Inaccurate synchronisation causes sample‑rate mismatch, leading to buffer over‑runs or under‑runs and audible clicks. The IEEE 1588 Precision Time Protocol (PTP) is the standard for distributing a high‑accuracy clock over Ethernet. The quality of the PTP implementation and the network’s ability to handle PTP messages (e.g., one‑step vs. two‑step clocks, boundary clocks) directly affect latency jitter. A poorly synchronised system may force devices to use larger jitter buffers, increasing latency. Choosing hardware that supports hardware‑timestamped PTP and deploying a proper PTP domain with a grandmaster clock are essential for sub‑millisecond latency stability.

Hardware Performance and Network Topology

Switches, cables, and endpoints all contribute to latency. Each switch introduces a switching latency (typically 1–10 µs) plus queuing delays. Unmanaged switches often lack QoS and can drop packets under load. Use managed Gigabit switches that support Ethernet AVB (Audio Video Bridging) standards or at minimum prioritise audio traffic with DSCP tags.

Network topology also matters. Daisy‑chaining switches adds cumulative latency; a star topology with a central core switch reduces hop count. Ensure all links operate at the same speed (1 Gbps minimum) to avoid autonegotiation mismatches that increase delay. Dedicate a separate VLAN or physical network for audio to eliminate contention from data traffic.

Advanced Strategies to Minimize AoIP Latency

Deploy Managed Switches with QoS and IGMP

Quality of Service (QoS) is the single most important tool for reducing latency in shared networks. Configure your switches to classify audio packets (using DSCP values such as CS4 or AF41) and place them in a high‑priority queue. Also enable IGMP snooping so that multicast audio streams are only forwarded to ports that request them, reducing unnecessary traffic on other ports.

Example QoS recommendations are available in the Audinate QoS guide.

Select an Appropriate Protocol and Packet Size

If you need absolute minimum latency, choose a protocol like Dante or Ravenna and set packet payload to 1 ms (or even 0.125 ms with certain Dante configurations). For less critical applications, 2–4 ms packets provide more robustness. Always test with your specific hardware, as some devices may not support the smallest payload sizes.

Use a Dedicated or Segmented Network

Isolating AoIP traffic on its own VLAN or physical network prevents interference from bursty data traffic (file transfers, web browsing, video). This dramatically reduces jitter and queueing delay. In large installations, use a core switch with enough backplane capacity to handle all audio channels simultaneously at line rate.

Implement Precise Clock Synchronisation (PTP)

Deploy a dedicated grandmaster clock (e.g., a GPS‑referenced PTP master) or use a switch that supports boundary clock functionality. Ensure all endpoints are PTP‑aware and configured to the same domain. Avoid daisy‑chaining PTP‑unaware switches because they degrade the clock distribution accuracy.

Optimise Jitter Buffer Settings

Start with the smallest buffer your network can handle reliably. On a well‑configured low‑jitter network, a 1‑ms jitter buffer at the receiver is often sufficient. Monitor packet loss and run‑time statistics; increase the buffer only if dropouts occur. Many modern AoIP devices allow per‑stream adjustment of buffer depth via software.

Use Hardware‑Accelerated Network Adapters

In computer‑based AoIP nodes (e.g., DAW computers), use network interface cards that support RSS (Receive Side Scaling) and TCP offload to reduce CPU load and interrupt latency. Alternatively, dedicated AoIP cards (e.g., Dante PCIe) handle the heavy lifting with very low latency.

Limit Network Diameter and Hop Count

Every switch hop adds a small but finite delay. For real‑time audio, keep the number of hops between source and destination to three or fewer. Use a collapsed‑core topology where endpoints connect directly to a central switch, avoiding long daisy chains.

Conclusion

Latency in Audio‑over‑IP systems is not an immutable property—it is a controllable parameter that can be optimised through careful network design, hardware selection, and protocol configuration. By understanding how bandwidth, packet sizing, protocol overhead, clocking, and topology interact, audio professionals can achieve end‑to‑end delays well below 1 ms, rivaling or even exceeding traditional digital snake systems. The key is to treat the network as an integral part of the audio signal chain, applying the same diligence to it as you would to microphones, mixing consoles, and amplifiers.

For further reading, consult the RTP specification (RFC 3550) for packetisation details, and the AVnu Alliance for standards on deterministic networking. With the right approach, your AoIP infrastructure will deliver pristine audio with negligible latency—enabling you to focus on creativity, not on network delays.