Understanding Latency in Audio over IP

Audio over IP (AoIP) technology replaces traditional point-to-point analog and digital audio connections with networked packet-based transport. This shift enables scalable, flexible, and cost‑effective audio distribution for live sound, broadcast, installed sound, and recording. However, the reliance on IP networks introduces latency—the time delay between an audio signal’s creation at the source and its reproduction at the destination. In real‑time applications such as live performance, studio monitoring, and intercom systems, even a few milliseconds of excess latency can cause echo, comb‑filtering, lip‑sync errors, or a loss of performer timing. Troubleshooting latency issues is therefore not a luxury but a requirement for professional AoIP deployments.

What Is Latency in AoIP?

Latency in AoIP is not a single value but a composite of several delay components. Understanding these layers is the first step toward effective troubleshooting.

End‑to‑End Latency

This is the total time from analog‑to‑digital conversion at the source through network transmission, buffering, and digital‑to‑analog conversion at the destination. End‑to‑end latency is the delay a user perceives.

Algorithmic Latency

Audio codecs and sample‑rate conversion algorithms introduce intentional delay. For example, linear PCM (uncompressed) adds minimal algorithmic delay, while lossy codecs like AAC or Opus may add several milliseconds of look‑ahead latency. In professional AoIP, uncompressed PCM (e.g., AES67 / Dante / RAVENNA) is standard, keeping algorithmic latency very low—often less than a sample period.

Network Latency

Packetization, serialization, store‑and‑forward switching, and propagation through cables and optical links all contribute. Gigabit Ethernet switches typically add less than 10 microseconds per hop, but queuing delays from congestion can blow this up to milliseconds.

Buffer Latency

Receive (jitter) buffers are used to smooth out packet arrival time variations. A larger buffer makes the system more resilient to network jitter but increases overall latency. Many AoIP systems allow the buffer size to be configured—often in increments of 0.25 ms, 1 ms, or 4 ms—directly affecting how much delay must be tolerated.

Common Root Causes of Elevated Latency

When end‑to‑end latency exceeds acceptable limits (typically < 5 ms for live monitoring, < 1 ms for IEM systems), the fault usually lies in one or more of the following areas.

Network Congestion and Bufferbloat

Excessive background traffic (file transfers, video streams, general IT data) competes with AoIP packets. Managed switches without strict Quality of Service (QoS) policies allow best‑effort packets to fill egress queues, causing latency spikes known as bufferbloat. Even momentary congestion can cause packet loss and retransmissions, further increasing delay.

Insufficient Bandwidth

Each uncompressed 48 kHz / 24‑bit audio channel requires approximately 1.5 Mbps of network bandwidth (including Ethernet and IP overhead). A 64‑channel Dante stream can consume over 100 Mbps. If the link capacity is exceeded—especially on 100BASE‑TX ports or when multiple streams converge on a single uplink—latency rises sharply due to packet dropping and reassembly delays.

Hardware Bottlenecks

Older switches with limited forwarding capacity, underpowered CPUs in AoIP nodes, or legacy network interface cards may not handle high packet rates efficiently. For example, a 64‑channel Dante stream generates roughly 8,000 packets per second (at 1 ms packet time). Some consumer‑grade switches cannot process that many interrupts without introducing latency.

Incorrect Configuration

Misconfigured IGMP snooping can flood multicast traffic to all ports, causing unnecessary processing. Disabled EEE (Energy‑Efficient Ethernet) or green Ethernet features are essential; power‑saving modes often increase latency by forcing ports into low‑power states. Similarly, spanning‑tree protocol (STP) convergence events can cause temporary loss of audio or delay.

Jitter and Packet Timing

Professional AoIP standards (AES67, SMPTE ST 2110‑30, Dante) rely on precise timing synchronization, typically via PTP (Precision Time Protocol) according to IEEE 1588‑2008. If PTP grandmaster clock stability is poor or the network introduces asymmetric delays, clock recovery becomes unstable. This forces nodes to use larger jitter buffers to avoid dropouts, increasing latency.

Packet Loss

Even a small packet loss rate (0.1%) in uncompressed AoIP can generate audible glitches. To mask losses, many implementations use error concealment or retransmission (ARQ). Both methods add delay: concealment introduces algorithmic latency, while retransmission waits for missing packets, increasing total end‑to‑end time.

Systematic Troubleshooting Methodology

A disciplined, layered approach isolates the root cause without guesswork. Follow these steps in order.

Step 1: Verify the AoIP System Baseline

Before touching the network, confirm the latency reported by the AoIP devices themselves. Many platforms (Dante Controller, RAVENNA tools, Livewire) display measured round‑trip or end‑to‑end latency. Document baseline values with all devices on the same managed switch under light load. If the baseline is already too high, look at device buffer settings and PTP synchronization quality.

Step 2: Isolate the Network

Disconnect all non‑audio traffic from the AoIP network. Temporarily remove any general‑purpose IT equipment, video streams, or internet access. Re‑measure latency. If the problem disappears, non‑audio traffic is the culprit. If latency remains high, move to Step 3.

Step 3: Measure Network Latency with Diagnostic Tools

Use tools like ping (for ICMP echo) or better, dedicated network latency testers such as iperf3 (for UDP latency) and ntopng for traffic analysis. Run iperf3 -u -b 100M -l 1472 between two endpoints to see if latency increases with load. Also enable packet loss statistics. High latency under load points to insufficient bandwidth or bufferbloat.

Step 4: Check Switch Configuration

Log into managed switches and verify:

  • IGMP snooping is enabled and querier configured.
  • QoS policies: prioritize DSCP EF (46) or CS5 (40) for AoIP traffic, with strict priority queuing.
  • EEE (Energy‑Efficient Ethernet) is disabled on all ports carrying AoIP.
  • STP is either disabled on audio VLANs or fast port‑fast features are enabled (to avoid convergence delays).
  • Jumbo frames (if supported) are enabled to reduce packet overhead, but note that some AoIP implementations fragment at 1500 bytes.

Step 5: Examine PTP Timing

Verify that all devices are locked to the same PTP domain and grandmaster. Use PTP management tools (e.g., ptp4l) to measure offset and mean path delay. An offset greater than 1 µs may cause buffer enlargement. Confirm that boundary clocks or transparent clocks are used on large networks to compensate for switch delays.

Step 6: Adjust Buffer Sizes

Most AoIP devices allow configuration of receive buffer size. Start with the firmware default (e.g., 4 ms for Dante). If latency is too high, try reducing to 1 ms. Then monitor for dropouts or packet loss. Gradually increase until reliable. Trade‑off: lower buffer = lower latency but less jitter tolerance.

Step 7: Test with a Minimal Topology

Connect two AoIP devices directly via an Ethernet cable (no switch). If latency drops dramatically, the switch or its configuration is the bottleneck. If not, the issue resides in the endpoints themselves.

Advanced Considerations for Low‑Latency AoIP

After resolving the immediate issue, consider these architectural improvements to prevent recurrence.

Dedicated Audio Network vs. Converged Network

Many engineers prefer a physically separate network for AoIP to isolate it from IT traffic storms. While VLANs with strict QoS can work on a single infrastructure, physical separation guarantees no competing traffic. For mission‑critical live events, dedicated hardware is standard.

Use of Managed Switches with Precise Timing

AES67‑compatible switches with IEEE 1588 support allow sub‑microsecond synchronization across many hops. Brands like Cisco Catalyst 9000 or Lumina offer specific AoIP profiles.

Redundancy and Latency Budget

Redundant streams (e.g., Dante’s secondary network, ST 2022‑7) can cause latency if both paths are not precisely trimmed. Always ensure redundant paths have equal delay to avoid glitches during failover.

Firmware and Driver Updates

Every AoIP device vendor periodically releases updates that improve buffer management or clocking. Check for updates from manufacturers like Audinate (Dante), RAVENNA, or Livewire and apply them during scheduled maintenance windows.

Best Practices for Designing a Low‑Latency AoIP System

  • Use wired Gigabit Ethernet exclusively. Avoid Wi‑Fi, powerline, or legacy 100 Mbps links.
  • Implement QoS from day one. Mark AoIP traffic with DSCP EF on endpoints and configure switches accordingly.
  • Set IGMP querier and snooping to restrict multicast traffic only to ports that need it.
  • Audit all non‑audio devices on the same VLAN. If they must share the network, place them on a separate VLAN with lower priority.
  • Consider using a dedicated PTP grandmaster (e.g., Meinberg or EndRun) rather than relying on a software‑based clock.
  • Test and measure latency continuously using tools integrated into your AoIP management software or external network analyzers like Wireshark with display filters for RTP payloads.
  • Document your final switch and device configurations so that future changes can be compared against a known good state.

Conclusion

Latency in Audio over IP deployments is rarely caused by one single factor. It is the result of interaction between network design, device configuration, clock synchronization, and traffic load. A methodical approach that isolates the network, verifies PTP timing, adjusts buffer sizes, and rigorously applies QoS will resolve the overwhelming majority of latency problems. By understanding the distinct contributions of algorithmic, network, and buffer latency, engineers can build AoIP systems that deliver sub‑millisecond performance suitable for the most demanding live sound and broadcast applications. Regular maintenance, firmware updates, and adherence to standards such as AES67 ensure that latency remains low and predictable, even as the system grows.