Understanding Signal Integrity in AES67 Audio Networks

Signal integrity testing is a critical practice for any professional deploying or maintaining AES67 audio-over-IP networks. AES67 allows devices from different manufacturers to exchange high-quality audio streams over standard Ethernet infrastructure, but this flexibility comes with stringent requirements for network timing, packet delivery, and jitter control. Without proper testing, even minor network imperfections can degrade audio quality, causing clicks, dropouts, or synchronization drift. This guide provides an in-depth, step‑by‑step approach to conducting signal integrity tests that ensure your AES67 network performs reliably in live production, broadcast, or installed sound environments.

The term “signal integrity” in AES67 networks goes beyond simple bit‑level correctness. It encompasses the timing accuracy of Precision Time Protocol (PTP) synchronization, the consistency of Real‑Time Transport Protocol (RTP) packet delivery, and the absorption of network-induced jitter by media clocks. A comprehensive test plan must verify all these dimensions. We will cover preparation, specific test methods, analysis of results, common issues, and ongoing monitoring, all with a focus on practical, production‑ready techniques.

AES67 and the Importance of Signal Integrity

AES67 is an interoperability standard published by the Audio Engineering Society. It defines how to transport high‑quality audio (up to 24‑bit, 96 kHz) over IP networks using RTP, PTPv2 (IEEE 1588‑2008), and Session Description Protocol (SDP). Because AES67 is not tied to a single vendor ecosystem, it must work over a wide range of switching hardware, cabling, and network topologies. This very flexibility makes network reliability and signal integrity paramount. Even a small amount of packet loss (<0.1%) can cause audible artifacts, while excessive jitter forces receiving devices to discard or re‑clock packets, leading to distortion.

Key performance parameters for AES67 networks include:

  • Latency – End‑to‑end audio delay must remain within predictable bounds (typically 1–4 ms for low‑latency profiles).
  • Jitter – The variation in packet arrival time should be less than the receiving device’s de‑jitter buffer (commonly 0.25–1 ms).
  • Packet loss – Even a few consecutive lost packets can cause an audible pop. Target loss below 0.01%.
  • PTP synchronization – Clock offset between devices must stay within ±1 µs to maintain phase‑aligned audio across channels.

Without rigorous signal integrity testing, these parameters can silently drift out of spec as network traffic changes, cables age, or firmware updates alter behavior. Regular testing catches degradation early, before it impacts a live event or critical recording.

Preparation for Signal Integrity Testing

Before you begin running tests, proper preparation ensures your results are meaningful and reproducible. Follow these steps to set the stage:

1. Verify Network Design and Configuration

  • Ensure all switches support IEEE 1588‑2008 (PTPv2) boundary or transparent clock functionality if using hardware timestamping. For simpler setups, end‑to‑end PTP works, but boundary clocks improve accuracy.
  • Enable IGMP snooping on every switch to constrain multicast audio streams only to ports that need them. Without this, streams flood the entire network, causing unnecessary congestion.
  • Configure Quality of Service (QoS) with strict priority for Ethernet frames carrying AES67 payloads. Assign a high DSCP (Differentiated Services Code Point) value (e.g., EF=46) to audio packets and a second high priority to PTP events.
  • Separate control traffic (like PTP management, SDP exchanges) from audio streams using VLANs. A dedicated Audio VLAN reduces contention.

2. Update Firmware and Drivers

All networked devices—switches, media converters, endpoints—should run the latest manufacturer‑recommended firmware. AES67 interoperability often improves with updates that fix PTP corner cases or multicast handling bugs. Document the firmware versions currently in use so you can correlate any test anomalies with specific builds.

3. Assemble Testing Tools

  • Network analyzer – Wireshark (free) with a capture point connected to a switch mirror port is the standard tool. For deeper PTP analysis, consider PTPv2-aware plug‑ins or commercial tools like PathWave.
  • IPerf2 or IPerf3 – Generates synthetic UDP traffic to simulate background load while testing audio stream resilience.
  • AES67 stream generator – Many manufacturers supply free tools (e.g., Audinate’s Dante Controller, but note Dante uses a proprietary layer over AES67; use pure AES67 generators for unambiguous testing). AES67 test stream generators can produce precise packet spacing.
  • Audio measurement interface – A device that both generates and receives AES67 streams, capable of reporting packet loss and jitter. Some professional sound cards now include AES67 support.
  • Cable tester – For copper Ethernet, verify all cables meet Category 5e or better, with no excessive crosstalk or length beyond 100 meters per segment. For fibre, check light levels and connector cleanliness.

4. Establish Baseline Metrics

Before making any changes or exposing the network to real traffic, run a set of baseline tests with no audio load. Measure switch CPU utilization, average and maximum latency, PTP offset, and multicast group membership states. Record these figures; they serve as the reference for all future comparisons.

Conducting Signal Integrity Tests

Now perform the core tests. Execute them in a logical order: connectivity, timing, stream quality, and stress testing.

Ping Test

Use simple ICMP ping commands to verify reachability between all AES67 endpoints and the PTP grandmaster. Pay attention to round‑trip time (RTT) and packet loss:

  • From a management station, ping each endpoint with a continuous count of 100 packets (e.g., ping -n 100 192.168.1.10 on Windows, ping -c 100 192.168.1.10 on Linux/macOS).
  • Acceptable RTT should be below 1 ms on a local switched network; anything higher may indicate congestion or a switch processing delay.
  • Zero packet loss is expected. Even one lost packet in 100 warrants investigation—it suggests saturated links or faulty hardware.

Note: ICMP is often handled differently from audio traffic (lower priority). A clean ping does not guarantee audio integrity, but poor ping results almost always indicate problems.

Packet Capture and Analysis

Packet captures provide the most granular view of network health. Connect your capture device to a switch port configured as a SPAN (mirror) port, covering both the audio VLAN and the PTP management traffic.

  • Start Wireshark and apply a display filter for RTP traffic: rtp or udp.port == 5004 (adjust port as per your SDP).
  • Inspect the RTP header timestamps. Consecutive RTP packets carrying 48 kHz audio should have timestamps increasing by exactly 192 (for 4 samples per packet) or 384 (for 8 samples per packet) each frame. Any discontinuity indicates a drop or misordered packet.
  • Use the Wireshark “Telephony → RTP → Show All Streams” tool to compute jitter and packet loss per stream. Pay attention to the “Max jitter” column—anything above 500 µs is a risk.
  • Filter for PTP event messages (UDP port 319). Verify that the grandmaster clock identity appears consistently and that follow‑up messages arrive within expected intervals (typically 1–8 per second). PTP offset analysis requires specialist tools, but simple command‑line pmc tools exist for Linux.

If you notice high jitter or packet loss, correlate the time with events like switch firmware updates, reboots, or heavy file transfers on shared VLANs. This points to configuration rather than hardware failure.

Stream Testing with Controlled Load

Generate a real AES67 audio stream from a known‑good source (e.g., a dedicated stream generator or a broadcast console with AES67 output). Have a receiving device decode the stream and report metrics.

  • Use a tool like IPerf3 on a separate machine to create background UDP traffic that simulates network load. Start with 50% of the available switch backplane bandwidth, then increase to 75% and 90% to stress‑test QoS behavior.
  • Monitor the receiving device’s audio output for audible clicks or pops. Many AES67 receivers log “buffer underrun” or “PTP slip” events.
  • Simultaneously capture packets with Wireshark. Compare jitter and loss under different load levels. A well‑configured AES67 network should show minimal increase in jitter even at 80% total link utilization, provided QoS is enforced.

Loopback Tests and End‑to‑End Verification

Loopback testing confirms that the entire signal path—from input to network to output—preserves waveform integrity. Use a device that can encode a known audio signal (e.g., a 1 kHz sine wave at –20 dBFS) and decode it on the same or a remote device, then compare the output to the original:

  • Connect an audio analyzer to the source’s analog output and measure the signal after it has been converted to AES67, transmitted, and reconverted. The frequency and amplitude should match.
  • For purely digital loopback, send the AES67 stream back to the originating device via a network path (often called “local loopback”). The re‑received stream should be bit‑identical to the transmitted one.
  • Any deviation—such as frequency offset >0.1 Hz or amplitude change >0.2 dB—indicates a synchronization problem or sample rate conversion irregularity.

Analyzing Test Results

After gathering data from captures, stream tests, and loopback measurements, you need to interpret the results against established thresholds.

Packet Loss Thresholds

For AES67 audio, the recommended packet loss limit is 0.01% or less. In a 30‑second capture at 48 kHz with 48‑sample packets (≈625 packets per second), that allows at most 3 lost packets. Higher loss requires immediate action: check for faulty cables, switch port errors, or misconfigured multicast pruning.

Jitter and Latency

Receiving devices have de‑jitter buffers sized to handle typical network jitter (commonly 1–4 ms). If your measured jitter (from the RTP stream analysis) exceeds 1 ms, you risk buffer underflows or overflows. Calculate the average jitter over a 10‑second interval; if it stays below 0.5 ms, your network is in good shape.

End‑to‑end latency depends on the device’s packet time (often 1 ms for 48‑sample frames) plus network propagation (negligible on a single switch) plus any buffer delay. Expect consistent latency within ±200 µs of the nominal value. Large variations point to PTP drift.

Synchronization Health

PTP offset and grandmaster stability are fundamental. Using the pmc tool or a dedicated PTP monitor, check the “offset from master” value for each ordinary clock. Offset should remain below 1 µs. If it drifts above that, examine the grandmaster clock source (e.g., GPS‑disciplined oscillator) and verify network symmetry (asymmetric PTP delays can cause offset).

Resolving Common Issues

Even with careful design, problems can appear. Below are frequent pain points and their solutions:

  • Excessive jitter under load – Verify that QoS is actually being applied. Check switch queuing configuration (strict priority for audio vs. weighted fair queuing). Disable power‑saving features (Energy‑Efficient Ethernet) on ports carrying audio.
  • Packet loss at specific switches – Inspect the switch’s error counters for CRC errors, collisions, or oversized frames. Replace patch cables, tighten connections, or move to fiber if interference is suspected.
  • PTP synchronization failures – Ensure all devices use the same PTP profile (default AES67 profile is IEEE 1588‑2008 with two‑step clock). If using boundary clocks, verify they are correctly transparent and not introducing delay asymmetry.
  • Audio dropouts during network events – Enable IGMP snooping and ensure the querier is elected properly. Use per‑VLAN spanning tree or MSTP to avoid broadcast storms. Disable RSTP on ports where audio endpoints reside (or use portfast).
  • Intermittent issues – Log all PTP and audio stream metrics to a remote server. Correlate high CPU load on switches (e.g., from firmware bugs) with dropout logs. Upgrade firmware as needed.

Regular Monitoring and Maintenance

Signal integrity testing is not a one‑time event. Build it into your operational routine:

  • Scheduled tests – Run a full battery of tests at intervals (monthly for critical systems, quarterly for less critical). Use automated scripts to generate reports from Wireshark captures and device logs.
  • SNMP monitoring – Configure switches to send SNMP traps for port errors, CPU, and memory. Use a network monitoring system (e.g., PRTG, Zabbix) to alert on anomalies before they become audible.
  • Firmware and configuration tracking – Maintain a version‑controlled repository of switch and endpoint configurations. Any change triggers a new baseline test.
  • PTP health dashboard – Deploy a lightweight PTP monitor that displays offset, delay, and clock class for all devices. Visualizing this data helps spot gradual drift.

Conclusion

Signal integrity testing for AES67 networks is a systematic process that combines network engineering knowledge with audio‑specific measurement techniques. By preparing your environment, using the right tools, and analyzing results against proven thresholds, you can ensure that your audio‑over‑IP system delivers consistent, high‑fidelity sound even under demanding conditions. The tests described here—ping, packet analysis, stream stress testing, and loopback verification—cover the essential dimensions of integrity: connectivity, timing, and data accuracy. Regular monitoring and proactive maintenance turn testing from a reactive chore into a strategic advantage, preventing disruptions before they reach the ears of your audience or clients.

For further reading, refer to the official AES67 standard document, the IEEE 802.1AS (PTP) specification, and practical guides from Audinate’s learning resources on network design for audio. These references will deepen your understanding of the underlying protocols and help you develop more robust test routines.