Understanding Latency and Jitter in AES67

AES67 defines the transport of high-quality digital audio over IP networks using RTP (Real-time Transport Protocol). Two critical performance metrics—latency and jitter—determine whether the system meets the demands of real-time audio. Latency is the total time from analog-to-digital conversion at the source to digital-to-analog conversion at the destination. Jitter describes the variability in packet arrival times relative to the expected clock. In professional environments, even small deviations in these parameters cause audible artifacts, lip-sync errors, and dropouts.

Latency: The End-to-End Delay Budget

Latency includes encoding, packetization, network transmission, buffering, and decoding. For live sound reinforcement, round-trip latency must remain below 10 milliseconds (ms) to avoid perceptible echo. Broadcast applications often require targets of 1–5 ms. Each component contributes: network switches introduce store-and-forward delays, audio interfaces add buffering latency, and codecs (if used) add algorithmic delay. Understanding these contributions is the first step toward optimization. A typical AES67 stream at 48 kHz with 1 ms packet time has a base latency of approximately 1 ms plus network transit and buffer delays. For critical applications, engineers target a total end-to-end latency of 2–3 ms or less.

Jitter: Time Variance in Packet Arrivals

In an ideal network, packets arrive at a constant interval—every 125 µs for a 125 µs packet time. Real networks introduce variance due to queuing, traffic bursts, switch fabric contention, and clock drift. Jitter causes the receiver’s playout buffer to either underrun (silence or clicks) or overrun (glitches). AES67 receivers use dejitter buffers to smooth variations, but excessive jitter forces the buffer to grow, increasing latency. A well-optimized AES67 network keeps jitter below 1 ms peak-to-peak; leading installations achieve 100–300 µs. Jitter tolerance depends on buffer size: a 1 ms buffer absorbs jitter up to ~0.5 ms, while a 3 ms buffer handles up to ~2 ms jitter.

Network Design for Deterministic Performance

The network is the shared medium for all AES67 streams. Poor infrastructure choices are the most common source of latency and jitter. Every element—cables, switches, routing, and services—must be selected and configured for deterministic performance.

Managed Switches and Quality of Service (QoS)

Unmanaged switches cannot prioritize AES67 traffic, leading to congestion and jitter. Deploy managed switches that support IEEE 802.1p (priority tagging) and DiffServ (Differentiated Services Code Point). Assign AES67 RTP traffic to the highest egress queue (queue 7) and use strict priority scheduling. Map DSCP 46 (Expedited Forwarding) to the priority queue. Additionally:

  • Disable energy-efficient Ethernet (EEE) because its power-saving modes add latency variance.
  • Enable flow control only if all endpoints support it; pause frames can introduce delay and should be tested carefully.
  • Set switch buffer sizes according to manufacturer recommendations for audio. Some switches allow adjusting buffer allocation per port; reserve sufficient buffer for audio ports.

For large-scale deployments, use scheduling algorithms like Weighted Strict Priority (WSP) or Deficit Weighted Round Robin (DWRR) with low latency queues. Always verify QoS with traffic generators and protocol analyzers.

VLANs and Traffic Isolation

Separating AES67 traffic onto a dedicated VLAN prevents competition from IT broadcasts, file transfers, and video streams. A single VLAN with strict QoS works for many setups, but for large deployments create a dedicated Audio VLAN with its own subnet. Configure IGMP snooping to limit multicast traffic to only ports that need it—otherwise, unnecessary multicast floods cause jitter. Use IGMP querier enabled on the switch.

Disable Spanning Tree Protocol (STP) on audio ports if the topology is simple. If STP is required (redundant links), use Rapid Spanning Tree (RSTP) with priority adjustments to ensure fast convergence without impacting streams. Enable PortFast (Cisco) or Edge Port (standard) on all access ports connected to audio endpoints.

Also disable unnecessary services on the audio VLAN: DHCP, DNS, NetBIOS, LLDP (if not needed), and any other broadcast-generating protocols. Each broadcast packet consumes buffer space and increases jitter variance.

Cabling and Physical Layer

Latency and jitter can originate from physical layer issues. Use Cat6a or better shielded twisted-pair cabling for Gigabit Ethernet links. For runs over 100 meters, use fiber optic connections with SFP transceivers; fiber eliminates electrical interference and provides consistent latency. Ensure all links operate at the highest common speed (1 Gbps or 10 Gbps) to minimize serialization delay. A 10 Gbps link serializes a 1500-byte packet in 1.2 µs, versus 12 µs on 1 Gbps. Avoid auto-negotiation issues by fixing speed and duplex on critical links.

Switch Selection Criteria for AoIP

Not all managed switches are equal. Look for switches with:

  • Low latency switching (cut-through forwarding preferred for audio, but many managed switches use store-and-forward; ensure forwarding latency is under 5 µs per hop).
  • Hardware timestamping for PTP (Boundary Clock or Transparent Clock support).
  • Sufficient multicast capacity (e.g., 4K+ multicast groups) and IGMP snooping.
  • Configurable egress buffer per port (at least 512 KB per port to handle bursts).

Vendors like Cisco (Catalyst 9300), Aruba (CX series), Netgear (M4300 series for AV), and Luminex (specifically for AoIP) offer appropriate models. Reference the Audinate Dante network design guide for network switch recommendations that apply to AES67 as well.

Advanced Buffer Management and Packetization Strategies

Modern AES67-compliant devices allow extensive configuration of buffer sizes and packet times. Incorrect settings are a leading cause of suboptimal performance.

Buffer Size Tuning

The playout (dejitter) buffer absorbs jitter but adds latency. The goal is the smallest buffer that reliably prevents underruns. Start with 1 ms (approximately 48 samples at 48 kHz). Gradually increase while monitoring error logs until underrun count drops to zero. For mission-critical applications, 2–3 ms provides safety margin. On the transmitter side, some devices allow tuning the transmit buffer; set it as low as the device supports (often 0.5–1 ms) to reduce base latency.

Consider using dynamic buffer adaptation if supported. Some AES67 implementations adjust buffer depth based on measured jitter in real time. Test under stress—for example, with simultaneous video and IT traffic—to validate buffer settings.

Packet Time Selection: 125 µs vs 1 ms vs 4 ms

AES67 supports packet times from 125 µs to 8 ms. Shorter packet times reduce latency but increase network overhead and CPU load. For live sound, 1 ms or 250 µs packets are common. Longer packet times (4–8 ms) may be used for non-real-time playback. At 48 kHz, a 1 ms packet contains 48 samples; a 125 µs packet contains 6 samples. The tradeoff:

  • 125 µs: Latency ~125 µs plus network delay. Overhead: 150+% (RTP header + payload). Requires high switch performance to handle many small packets.
  • 1 ms: Latency ~1 ms plus network. Overhead: ~20%.
  • 4 ms: Latency ~4 ms plus network. Overhead: ~5%. Acceptable for playback but not for live.

Ensure all devices in a flow agree on the same packet time. Some converters allow automatic negotiation; verify manually during commissioning.

Forward Error Correction (FEC) and Redundancy

AES67 does not mandate FEC, but some implementations add it (e.g., RTP redundancy or SMPTE 2022-7). FEC can recover lost packets at the cost of additional bandwidth and latency (1–2 ms). Use FEC only on unreliable networks; for controlled LANs, rely on QoS and buffer tuning. Redundant network paths (dual switch, dual NIC) with hitless switching are available in some AES67 extensions and should be tested for jitter impact during failover.

Precision Timing with PTP

AES67 decouples streaming from system-wide synchronization through a dedicated clock, typically derived from Precision Time Protocol (PTP). Without accurate timing, jitter increases and clock drift leads to buffer overflows.

PTP Grandmaster Selection and Configuration

Use a hardware-timestamping grandmaster (e.g., dedicated PTP-enabled switch or audio interface). Configure all endpoints as ordinary clocks. The PTP domain number must be consistent (default 0 for AES67). Set PTP sync interval to 1 second (logSyncInterval = 0) and announce interval to 2 seconds. For networks with more than 10 hops, use boundary clocks to reduce jitter accumulation. A poorly configured PTP domain—mismatched profiles, incorrect grandmaster priority—can become a source of jitter.

Key PTP parameters:

  • Clock class: Set grandmaster clock class to 6 (primary reference), endpoints to 248 (default).
  • Clock accuracy: Aim for accuracy of 0.001 µs (scale 0x21).
  • Priority1 and Priority2: Set lower values for the designated grandmaster to ensure consistent selection.

Use a GNSS-disciplined oscillator for the grandmaster. Rubidium or OCXO references improve stability further.

Boundary Clocks and Transparent Clocks

In large networks, PTP messages traverse multiple switches. Boundary clocks (BC) or transparent clocks (TC) compensate for switch delays. BCs act as PTP-aware switches that regenerate sync messages; they require hardware timestamping. TCs modify PTP messages to correct residence time. For AES67, the Audio Video Bridging (AVB) profile uses TCs, while AES67 standard Profile often relies on BCs. Ensure switch PTP configuration follows the AES67 profile (IEEE 1588-2008 with default profile settings). Test clock synchronization with PTP monitoring tools to verify offset and jitter.

Clock Domains and Sample Clock Locking

AES67 devices can use different clock domains: sample clock (for audio conversion) and network clock (for PTP). Ideally, both derive from the same master clock to eliminate drift. Many professional devices allow sample clock lock to PTP using an internal PLL. Verify that the PTP grandmaster is stable and that endpoints use the same clock source. In the event of grandmaster failure, automatic failover to another master should be configured, but note that failover causes a brief jitter spike. Test failover during commissioning.

Monitoring and Proactive Troubleshooting

Even with careful design, real-world networks introduce variables. Continuous monitoring is essential to maintain low latency and jitter over time.

Network Analysis Tools

Use dedicated AoIP analysis software to measure jitter, packet loss, and latency. For AES67, tools like Dante Controller (shows latency and errors), Wireshark with RTP analysis, and specialized testers (e.g., Audio Precision APx500, RME Digicheck) provide deep insight. Capture RTP packets and examine timestamps and sequence numbers. Jitter can be calculated per RTCP definition (interarrival jitter). Set up SNMP monitoring on switches to track queuing delays and error counters. For proactive management, create alerts when jitter exceeds 0.5 ms or latency exceeds the budget.

Additional metrics to monitor:

  • PTP offset (should be < 1 µs).
  • PTP path delay (should be < 100 µs for local networks).
  • Switch CPU utilization (high utilization can cause schedule delays).
  • Port queue discards (indicate buffer overflows).

Firmware and Software Updates

Keep all devices on the latest stable firmware. Manufacturers frequently release improvements to PTP profiles, buffer algorithms, and QoS handling. Document firmware versions and maintain a changelog. A single outdated switch can degrade the entire network. Test firmware updates in a staging environment before production.

Common Pitfalls and Fixes

  • Mixed link speeds: A 100 Mbps switch port in a Gigabit network creates a bottleneck that increases jitter. Ensure all ports operate at the highest common speed.
  • Spanning Tree updates: If STP reconverges, audio streams may drop. Use PortFast or edge ports for all audio devices.
  • Unnecessary services: Disable DHCP, DNS, and other IP services on audio-only VLANs to reduce broadcast noise.
  • Clock drift: Verify that the grandmaster is locked to an external reference (GNSS or word clock) and that all endpoints use the same clock source.
  • Switch buffer allocation: Some switches share buffers across ports; heavy traffic on one port can affect others. Use port-based buffer reservation if available.

Conclusion

Optimizing latency and jitter in AES67 networks requires a disciplined approach to network hardware, device configuration, and timing infrastructure. By using managed switches with QoS, isolating audio traffic on a dedicated VLAN, tuning buffer sizes, and implementing precise PTP synchronization, engineers can achieve sub-millisecond latency and jitter suitable for the most demanding live and broadcast applications. Regular monitoring and adherence to best practices ensure system stability as the network evolves. For further reading, consult the AES67 standard from the Audio Engineering Society, the IEEE 1588 Precision Time Protocol resources from NIST, and network QoS configuration guides from your switch vendor. The effort invested in design and testing pays dividends in reliable, high-quality audio transmission.