The Critical Role of Latency in AES67 Audio Networks

AES67 has emerged as the dominant standard for high-performance, interoperable audio-over-IP transmission, serving live sound reinforcement, broadcast production, installed sound systems, and recording studios. Its promise of deterministic, sample-accurate audio delivery over standard Ethernet networks hinges on one variable: latency. Even a few milliseconds of excess delay can create audible comb filtering, echoes, lip-sync errors in video applications, or disrupted foldback mixes for performers. Understanding and controlling the sources of delay is essential for deploying production-ready AES67 systems that deliver pristine audio under demanding real-time conditions. This article breaks down every contributor to network latency, explains how to measure them accurately, and provides actionable strategies to reduce end-to-end delay without sacrificing reliability or audio quality.

What Is Latency in AES67 Networks?

In the context of AES67, latency is the total time elapsed from when an audio sample is captured by an analog-to-digital converter (ADC) at the source until it is reproduced by the receiving device’s digital-to-analog converter (DAC). This end-to-end delay is not a single value but the sum of discrete stages in the signal chain:

  • Acquisition delay – The time required for analog-to-digital conversion plus any initial buffering in the source device’s input stage.
  • Packetization delay – The time needed to fill an RTP payload with audio samples. For a given packet time (125 µs, 250 µs, 333 µs, 1 ms, or 4 ms), the encoder waits until enough samples are collected before transmitting.
  • Network transit delay – The propagation time through cables, switches, and routers, including serialization, switching, and queuing delays. This is typically the smallest component in well-designed networks.
  • De-jitter buffer delay – The receiving device’s buffer that smooths out timing variations (jitter) in packet arrival times. Larger buffers increase latency but protect against dropouts.
  • Playback delay – The output-side digital-to-analog conversion and any output buffering or processing (e.g., sample rate conversion, DSP effects).

AES67-compliant systems can operate within a total latency range of 1 ms to 10 ms under optimal conditions. The chosen packet time directly influences both the packetization delay and the required jitter buffer size. The engineering challenge is to select the lowest feasible packet time that the network infrastructure and all connected devices can support without instability or data loss.

The AES67-2015 standard defines mandatory and optional packet times, with 1 ms being the most universally supported. Sub-millisecond options (125 µs, 250 µs, 333 µs) exist for low-latency applications but require careful validation across the entire signal path.

Key Factors Affecting Latency

Network Traffic and Congestion

AES67 transports audio using RTP (Real-time Transport Protocol) over UDP. Unlike TCP, UDP provides no retransmission of lost packets—any packet dropped in transit results in an audible gap. When the network carries high levels of non-critical traffic (file transfers, video streams, automatic backups), switch buffers can become congested, causing variable queuing delays (jitter) and packet loss. Managed Ethernet switches with dedicated audio VLANs and properly configured Quality of Service (QoS) are non-negotiable for isolating AES67 traffic from best-effort data. Without segmentation, a single large file download can disrupt an entire audio session.

Hardware Performance

Every physical component introduces measurable delay. Network interface cards (NICs) that support hardware timestamping (IEEE 1588) significantly reduce PTP scheduling jitter compared to software-only implementations. Switches with cut-through forwarding can reduce per-hop latency from over 10 µs (store-and-forward) to below 5 µs. On the audio device side, the speed of DSP or FPGA logic determines how quickly samples are converted, aggregated, and encapsulated into RTP packets. Choose equipment rated for real-time media workflows—enterprise-grade managed switches with sub-5 µs port-to-port latency and audio interfaces with dedicated AES67 hardware acceleration are recommended for professional deployments.

Packet Size and Packet Time

The packet time (also called the “packetization interval”) directly determines how many audio samples are bundled into each RTP payload. A 1 ms packet at 48 kHz holds 48 samples; a 125 µs packet holds only 6 samples. Shorter packet times reduce the packetization delay component but proportionally increase the number of packets per second, raising CPU load, interrupt frequency, and the bandwidth overhead from Ethernet and IP headers. For example, a single 48 kHz / 24-bit / 2-channel stream at 125 µs generates 8000 packets/second; at 1 ms it generates 1000 packets/second. Select the smallest packet time that your entire network chain can handle without frame loss or excessive CPU utilization. Many production environments default to 1 ms as a balanced safe choice, but live monitoring applications may require 250 µs or 125 µs. Always validate with a full load test before going live.

Switching Equipment Configuration

Not all network switches are suitable for AES67. The following features are critical for minimizing latency:

  • Quality of Service (QoS) – Prioritize AES67 audio packets by marking them with DSCP value 46 (Expedited Forwarding) or 34 (Assured Forwarding). On the switch, map these DSCP values to the highest-priority hardware queue to ensure they are never delayed behind bulk traffic.
  • Multicast filtering (IGMP snooping) – AES67 typically uses IP multicast. IGMP snooping restricts audio streams to only those ports that have subscribed, preventing unnecessary traffic on other links and reducing the risk of buffer bloat.
  • Jumbo frames – AES67 works fine with standard 1500-byte MTU, but some implementations support larger frames. Enable jumbo frames only if every device in the path supports them consistently.
  • Cut-through switching – Enables forwarding to begin as soon as the destination MAC address is read, shaving microseconds per hop. Verify that your switch supports cut-through on the specific port types and speeds you are using.

Clock Synchronization

AES67 relies on IEEE 1588-2008 (Precision Time Protocol, PTP) to synchronize sample clocks across all devices. The PTP profile defined in AES67 uses a default domain (domain 0) and specifies ordinary clocks and boundary clocks. Poor PTP implementation—such as long sync intervals, high network jitter on PTP messages, or failure to deploy boundary clocks in multi-switch networks—forces receivers to enlarge their jitter buffers to absorb timing drift. This directly increases overall latency. Deploy a stable grandmaster clock (e.g., using an OCXO-based oscillator) and place boundary clocks at each switch to regenerate sync messages. Keeping PTP offset under 1 µs allows you to reduce jitter buffer sizes and achieve lower end-to-end delay.

Jitter Buffer Management

The de-jitter buffer at each receiver is the final line of defense against network timing variations. It must be large enough to accommodate the worst-case jitter without underrunning (which produces audio gaps), but every millisecond of buffer adds latency. Most AES67 devices offer both manual and adaptive buffer settings. Start with a buffer size of one to two packet times and monitor packet loss statistics. If no losses occur over a representative period, try reducing the buffer. Adaptive buffers automatically shrink during stable network conditions and expand only when jitter spikes, offering a good compromise. In critical applications, manually setting a fixed buffer that has been validated under peak load is often safer.

Measuring Latency in AES67 Networks

Accurate measurement is essential for optimizing latency. Several practical methods provide insight into different parts of the signal chain:

  • RTP timestamp analysis – Each RTP packet carries a timestamp derived from the PTP clock. By comparing the send and receive timestamps (with clock offset correction), you can calculate one-way network transit delay. Tools like Wireshark can decode RTP headers and present this information.
  • Network analyzers – Wireshark with the “aes67” display filter isolates audio packets. The “RTP Streams” dialog shows sequence numbers, timestamps, and jitter statistics. For deeper analysis, enable “Tools → RTP → Show All Streams” to visualise timing.
  • End-to-end loopback test – Route a test signal (e.g., a periodic pulse) from an analog output, through an ADC, across the network, and back into the same device. Compare the original and returned signal on an oscilloscope or in audio measurement software like Room EQ Wizard (REW) or Audio Precision. The measured delay includes all conversion and buffering.
  • PTP offset logs – Most AES67 devices provide a dashboard or log showing the current offset from the grandmaster clock. Persistent offsets greater than 1 µs indicate sync problems that will force larger jitter buffers. Monitor this value over time to detect sporadic network congestion affecting PTP.

For reference, consult RFC 3550 – RTP: A Transport Protocol for Real-Time Applications for timestamp details, and the AES67-2015 standard for specification of mandatory measurement procedures.

Strategies to Minimize Latency

1. Dedicated Audio Network with VLAN Segmentation

Separate AES67 traffic from office data and general IT traffic using an IEEE 802.1Q VLAN. This eliminates the risk of congestion from non-real-time applications such as file backups, email, or web browsing. Configure the audio VLAN with the highest QoS priority. A flat, unsegmented network is the most common cause of unacceptable latency and packet loss in AES67 deployments. Use a dedicated physical network if possible, or at minimum a VLAN with strict traffic isolation.

2. Enable and Verify Quality of Service (QoS)

Set DSCP to 46 (Expedited Forwarding) for audio RTP streams and to 34 (Assured Forwarding 41) for PTP event messages. On Cisco switches, enable mls qos trust dscp on ports connecting to audio devices; on other platforms, map DSCP values to the highest available egress queue. After configuration, stress-test with a traffic generator to ensure that audio packets are never dropped when competing traffic peaks. Verify using switch QoS counters.

3. Choose Managed Switches with Cut-Through Mode

Cut-through forwarding reduces switch latency to under 5 µs per hop. Many enterprise switches—such as the Cisco Catalyst 9300 series, Netgear M4250 series, or Aruba 2930F—support per-port cut-through configuration. Verify that cut-through is compatible with the packet sizes of your AES67 streams; some switches fall back to store-and-forward for packets that require error checking on the fly. In practice, modern managed switches handle this well, but always confirm in the datasheet.

4. Optimize PTP Configuration

Use a dedicated grandmaster clock with high stability (OCXO or better). In multi-switch topologies, configure each switch as a boundary clock to regenerate PTP messages and prevent jitter accumulation. Keep all devices in the same PTP domain (default 0 for AES67). Avoid chaining ordinary clocks without boundary clocks across multiple switch hops; this leads to cumulative timing errors that force larger jitter buffers. Monitor PTP offset logs to confirm stability within 1 µs.

5. Minimize Network Hops

Each switch hop adds processing and potential queuing latency. Design a star topology where all audio sources connect directly to a single core switch. If multiple switches are necessary, interlink them with high-bandwidth trunks (10 GbE or higher) and configure PTP boundary clocks at each hop. Keep the number of hops between any source and receiver to three or fewer.

6. Use Small Packet Times with Caution

Packet times of 125 µs or 250 µs offer the lowest latency but place high demands on CPU and network throughput. If your application demands sub-millisecond latency (e.g., in-ear monitoring for live performance), verify that every device in the path supports the chosen packet time and that the network can handle the resulting packet rate without loss. Test all streams simultaneously at the target packet time in a worst-case scenario. For many broadcast and installed sound applications, 1 ms provides excellent performance with significantly lower overhead.

7. Keep Firmware and Drivers Up to Date

Network switch firmware, audio device firmware, and NIC drivers receive ongoing improvements for PTP stability, QoS handling, and packet processing efficiency. Check manufacturer release notes for fixes specifically related to AES67 or RTP. Schedule firmware updates during maintenance windows and validate after each update.

8. Limit Non-Audio Traffic During Critical Sessions

Even with QoS, extreme congestion can cause jitter. During live broadcasts, performances, or recording sessions, disable automatic backups, software updates, and large file transfers on the audio VLAN. Use traffic shaping at the network edge to cap non-audio bandwidth to a percentage of the link capacity.

Advanced Considerations

Multicast vs. Unicast

AES67 typically uses IP multicast to efficiently distribute one stream to many receivers. Multicast requires IGMP snooping on switches to avoid flooding all ports. Misconfigured IGMP—such as a missing querier or disabled snooping—can cause unnecessary traffic on unrelated ports, increasing latency and jitter. For point-to-point applications, unicast is simpler and eliminates multicast overhead. Verify that IGMP snooping is active and that the querier is correctly configured on the VLAN. In dense multicast environments, consider using IGMP filtering to limit stream distribution.

Redundancy and ST 2022-7

AES67 can incorporate SMPTE ST 2022-7 seamless protection redundancy, where the same stream is sent over two separate network paths. The receiver must align the two flows before playback, which requires a jitter buffer large enough to hold the path delay difference (typically 1–4 ms). If low latency is a higher priority than hitless redundancy, consider disabling ST 2022-7 on links where cable faults are unlikely, especially in single-path environments such as a broadcast control room.

Link aggregation (LAG) increases bandwidth between switches but does not reduce per-packet latency. Some LAG hashing algorithms may reorder packets if flows are split across physical links, which can disrupt RTP streaming. For AES67 applications, using a single high-speed link (10 GbE or 25 GbE) is preferable to aggregating multiple 1 GbE links, as it avoids packet ordering issues and simplifies troubleshooting.

Troubleshooting Common Latency Issues

Even with careful planning, latency problems can arise. Use the following checklist to diagnose and resolve them:

  • Packet loss is present – Check switch port error counters. Enable QoS and verify that audio traffic is not being dropped by comparing “no buffer” or “queue full” counters before and during load.
  • Jitter exceeds 2 ms – Look for PTP offset drift, heavy non-audio traffic on the same VLAN, or missing boundary clocks. Use Wireshark to measure jitter from RTP timestamps.
  • End-to-end delay is higher than expected – Verify that the jitter buffer size is not set too conservatively. Test with a smaller buffer and monitor for dropouts. Also check for additional processing delays in the audio device (e.g., sample rate conversion or DSP effects added unintentionally).
  • Intermittent dropouts only during peak times – Likely congestion from non-audio traffic. Confirm VLAN segregation and QoS settings. Use a managed switch with per‑port bandwidth limits to cap non-critical traffic.
  • Sub-millisecond packet times cause CPU overload – Upgrade the audio device’s firmware or NIC driver. If the device cannot handle the packet rate, increase packet time to 1 ms as a fallback.

Conclusion

Minimizing latency in AES67 audio networks requires a comprehensive, system-level approach. Hardware selection, network segmentation, QoS configuration, PTP synchronization, and jitter buffer tuning all influence the final end-to-end delay. By isolating audio traffic, deploying managed switches with cut-through forwarding, maintaining a stable PTP domain, and carefully matching packet times to your infrastructure capabilities, professionals can achieve total delays below 2 ms while preserving audio integrity. For mission-critical applications, regular measurement using the techniques described here—combined with incremental optimization—will ensure your AES67 network performs reliably even under heavy load. Reference the AES standards page for the latest technical documents, and consult Audinate’s AES67 FAQ for practical deployment tips. With careful planning and validation, AES67 can deliver the low latency and high reliability that modern audio production demands.