Understanding AES67 and Signal Integrity

AES67 is an Audio Engineering Society standard that defines interoperability for high-performance audio-over-IP (AoIP) networks. It ensures that equipment from different manufacturers—such as mixing consoles, amplifiers, and digital signal processors—can share audio streams with deterministic timing and minimal signal degradation. The standard leverages existing network protocols like RTP, UDP, and PTPv2 (IEEE 1588-2008) to deliver synchronized, low-latency audio across standard Ethernet infrastructure.

Signal integrity in AES67 networks is the fidelity with which the digital audio waveform is preserved from source to destination. Unlike analog systems, where signal degradation is gradual (noise, distortion, frequency roll-off), digital integrity involves timing, packet delivery, and clock accuracy. Key metrics include:

  • Jitter: The variation in packet arrival times caused by network congestion, clock drift, or buffering. Excessive jitter forces receivers to drop or extrapolate samples, introducing audible artifacts.
  • Latency: The end-to-end delay from signal generation to reproduction. AES67 requires consistent low latency, typically below 1 ms per hop, but cumulative latency can degrade real-time performance.
  • Packet Loss: Missing packets due to bit errors, buffer overflows, or link failures. Even 0.1% loss can cause clicks, pops, or dropouts in uncompressed audio.
  • Clock Synchronization (PTP): AES67 mandates Precision Time Protocol to synchronize all devices within microsecond accuracy. Misalignment in clock synchronization leads to buffer underruns or overruns, causing glitches.
  • Signal-to-Noise Ratio (SNR): In AES67, SNR translates to bit error rate (BER). High BER due to electromagnetic interference or poor cabling degrades the digital signal, potentially dropping packets or corrupting data.

The goal of signal integrity testing is to verify that the entire signal chain—from source codec, through network switches, to destination decoder—operates within the tolerances defined by the AES67 standard and the application’s quality requirements. Without rigorous testing, seemingly minor issues like a slightly underpowered PoE switch or an inappropriate cable length can cascade into system-wide failures during a live performance or critical broadcast.

Preparing for Signal Integrity Testing

Effective testing begins long before you connect an analyzer to the network. Inadequate preparation often leads to false positives, missed faults, or wasted time. The following preparation steps establish a baseline environment that isolates signal integrity issues from configuration problems.

Network Design and Infrastructure Verification

Start by confirming that your network topology supports AES67’s requirements. This includes:

  • Switches: Use managed switches with IGMP snooping, QoS (DSCP 46 for audio, 34 for PTP), and adequate port buffers. Switches must handle multicast efficiently without dropping packets under load.
  • Cabling: Cat5e, Cat6, or Cat6a cables rated for at least 1 Gbps. Avoid using existing building network cables unless they have been certified for high-frequency data transmission. Cable lengths should stay within 100 meters per run; longer runs require switches or media converters.
  • Power over Ethernet (PoE): Verify that PoE sources can supply sufficient power to all devices without voltage droop, which can cause transceiver jitter.

Essential Tools and Equipment

Investing in the right equipment is non-negotiable for thorough testing. The following tools address different aspects of signal integrity:

  • Network Analyzers (e.g., Wireshark with RTP/RTCP dissectors, iPerf3 for bandwidth testing). For AES67-specific messaging, tools like Wireshark can decode PTP, RTP, and SAP packets to verify stream parameters.
  • PTP Grandmaster Clock or Analyzer (e.g., Meinberg or EndRun Technologies devices) to measure offset, mean path delay, and sync interval across the network.
  • RTP / Audio Stream Monitor – Software like Digigram Headquarter or Audinate’s Dante Controller (which also supports AES67) can display packet timing, latency, and stream health.
  • Oscilloscope or Protocol Analyzer (optional) – For physical-layer checks at the transmitter output, especially if you suspect impedance mismatch or transition degradation.
  • Loopback Adapters – Termination adapters for RJ45 ports that allow a device to receive its own transmitted signal for simple round-trip delay tests.

Before testing, update all firmware and drivers on the equipment under test. Many signal integrity issues—especially with PTP locking—are solved in software updates that improve clock recovery algorithms.

Step-by-Step Signal Integrity Testing Procedures

The following systematic approach ensures no critical parameter is overlooked. Perform these tests during a maintenance window to avoid affecting active audio users.

1. Verify Network Configuration

Configuration errors cause the highest percentage of signal integrity problems in AES67 networks. Begin with:

  • IP Address and Subnet: All devices must be on the same subnet unless using layer-3 routing with PTP boundary clocks. Conflicting subnets lead to unroutable multicast traffic.
  • Multicast Addressing: AES67 uses multicast for audio streams. Verify that multicast groups are correctly defined and that IGMP snooping is enabled on switches to prevent flooding.
  • PTP Configuration: Check the PTP domain number (default 0), sync interval (typically 1 Hz to 64 Hz), and announcement interval. All devices must be set to the same domain. Use a PTP analyzer to confirm that slave devices lock to the grandmaster with an offset below 1 µs.
  • QoS and DSCP Markings: Ensure that audio traffic is tagged with DSCP 46 (Expedited Forwarding) and PTP with DSCP 34 (Assured Forwarding). Mismatched QoS can introduce jitter during high load.

2. Conduct Loopback Tests

Loopback tests isolate the source-to-destination path by having a device send its own stream back to itself (if supported) or by using a dedicated loopback adapter. This identifies:

  • Packet Loss: Compare the transmitted packet count to the received count. Any difference indicates a hardware or software issue.
  • Round-Trip Latency: Measure the time from transmission to reception. If latency exceeds the expected network delay plus processing time, you may have buffer bloat or switch congestion.
  • Jitter: Analyze the inter-packet arrival times. AES67 requires jitter below 1 ms for most codecs; higher jitter demands larger receive buffers, increasing overall latency.

Perform loopback tests at both 48 kHz and 96 kHz sample rates if the equipment supports them, as higher sample rates impose stricter timing requirements.

3. Analyze Signal Quality with Network Analyzers

Connect a network analyzer——either a dedicated hardware probe or a laptop running Wireshark——to a SPAN port (port mirror) on the switch handling the audio streams. Analyze the live traffic:

  • RTP Sequence Numbers: Gaps in sequence numbers indicate lost packets. Wireshark’s RTP analysis tool shows loss percentage, jitter, and max time between packets.
  • PTP Offset and Delay: Filter on PTP event messages (Sync, Follow_Up, Delay_Req, Delay_Resp). Record the master-slave offset and mean path delay. A stable offset under 500 ns is ideal; if it drifts beyond 1 µs, investigate clock quality or network asymmetry.
  • Packet Duplication: Unexpected duplicate packets can confuse receivers and waste bandwidth. Check for duplicates via sequence number analysis.
  • Bandwidth Utilization: Ensure that total traffic (audio + PTP + other data) does not exceed 70% of any link capacity. High utilization increases queuing delay and jitter.

Save packet captures for baseline comparison during future tests. Document the network load conditions (e.g., number of active streams, sample rates) at the time of capture.

4. Stress Testing with Synthetic Traffic

To verify that the network handles worst-case scenarios, generate synthetic audio streams at the maximum expected sample rate and channel count. Use a tool like iPerf3 to create background UDP traffic while measuring audio quality. Look for:

  • Packet Loss Under Load: Increase background traffic incrementally until the audio stream shows 0.1% loss or more. That point marks the network’s capacity limit.
  • Jitter Spikes: Monitor jitter during background traffic bursts. Large spikes indicate switch buffer exhaustion or poor QoS queuing.
  • PTP Stability Under Load: Even non-audio traffic can affect PTP timing if the switch handles PTP packets with lower priority. Stress tests should include flooding the network with high-priority best-effort traffic to see if PTP offsets increase.

If the network fails stress tests, consider upgrading switch hardware, increasing link speed, or segmenting the audio network from other data traffic.

5. Test with Real Audio Streams

Synthetic tests are necessary but not sufficient. Real audio streams contain varying signal levels, silence, and transients that can stress encoding/decoding differently. Connect a high-quality audio source (like a test tone generator or live microphone feed) and encode it into an AES67 stream. Then:

  • Subjective Listening: Have an experienced audio engineer listen for artifacts: clicks, pops, static, or dropout. Note the time and correlate with network metrics recorded by the monitoring software.
  • Objective Measurement: Use a digital audio analyzer at the destination to measure THD+N, dynamic range, and frequency response. Compare these values to the source. Any degradation indicates a signal integrity issue, even if packet loss is zero, because clock jitter can cause bit errors.
  • Long-Duration Test: Run the stream for at least eight hours (or overnight) to capture intermittent faults caused by temperature changes, device clock drift, or network uplink failovers.

Document the audio content, encoder settings, and network conditions. If tests reveal anomalies, isolate the problem by swapping components (cables, switch ports, devices) and repeating the test.

6. Verify System Redundancy and Failover

In critical installations, AES67 networks often include redundant paths via redundant switches, link aggregation, or dual-homed endpoints. Test signal integrity during a failover scenario:

  • Link Failure: Manually unplug a primary link and measure the gap in audio delivery. For seamless operation, the gap should be less than the sample buffer (typically 1–4 ms). Longer gaps cause audible dropouts.
  • Switch Failure: If using redundant switches, power off the primary switch while monitoring audio. Verify that the secondary path maintains both PTP sync and audio stream integrity within specifications.
  • PTP Grandmaster Failover: If you have multiple grandmaster clocks, simulate a failure of the primary. The network should automatically promote a backup grandmaster, and all slaves should re-lock within a few seconds without generating audio glitches.

Failover tests are often overlooked but are essential for ensuring that redundancy actually works during a crisis. Document the failover timing and any packet loss or jitter spikes.

Advanced Testing Techniques

For systems demanding the highest reliability—such as broadcast studios, live concert venues, or mission-critical intercoms—advanced tests can uncover subtle issues that basic testing misses.

PTP Stability Analysis

Use a dedicated PTP traffic analyzer that logs offset, path delay, and sync interval over hours. Calculate metrics like:

  • Mean Time Between Outliers (MTBO): How often does the offset exceed 1 µs in a stable network? A low MTBO indicates clock instability.
  • Wander: Slow drift of clock offset (measured in ppm) over minutes. Wander can cause long-term audio drift if receivers don’t resample frequently.

Quality of Service (QoS) Auditing

Misconfigured QoS is a common source of jitter. Run a packet capture and filter on DSCP values. Every audio and PTP packet should have the correct marking. Use tools to verify that switches are honoring the markings in their queuing policies (strict priority vs. weighted fair queueing).

Electromagnetic Interference (EMI) Immunity Check

In large installations with heavy lighting dimmers or industrial machinery, electromagnetic interference can increase bit errors. Temporarily place a portable AM radio near the cable paths (it can pick up broadband EMI) or use a cable certifier that measures BER under induced noise.

For facilities that already have a paging system or older analog infrastructure, test with a digital audio analyzer that measures jitter directly from the AES/EBU output of the receiving device. This gives an absolute measurement of recovered clock quality.

Best Practices for Maintaining Signal Integrity

Signal integrity isn’t a one-time check—it must be maintained throughout the system’s lifecycle. Implement these best practices in your workflow.

Use Quality Components

Not all switches, cables, and connectors are equal. Select managed switches with low latency (< 2 µs switching), large buffer pools, and support for IEEE 1588 transparent or boundary clocks. For cabling, choose plenum-rated Cat6a shielded twisted pair (STP) to reduce interference. Avoid using consumer-grade wireless bridges for audio streams, as they introduce jitter and periodic dropout.

Keep Firmware and Software Updated

Manufacturers frequently release updates that improve PTP synchronization, reduce jitter, or fix packet handling bugs. Subscribe to notifications for your AES67 devices and switches. Schedule a maintenance window every six months to apply updates and re-run baseline tests.

Implement Network Redundancy

Redundancy doesn’t just protect against hardware failure—it can also improve signal integrity by providing alternate paths that may have lower load. Configure:

  • Link Aggregation (LACP) between switches to increase bandwidth and provide automatic failover for individual links.
  • Separate VLAN for Audio to isolate audio traffic from data traffic that could cause congestion.
  • Dual-Homed Endpoints (if supported) so the receiving device can switch between two network paths without packet loss.

Regular Monitoring and Documentation

Deploy a centralized monitoring solution (e.g., PRTG, SolarWinds, or a custom script using Wireshark CLI) that polls each AES67 device’s PTP offset, stream packet loss, and CPU temperature. Set thresholds for alerting (e.g., offset > 1 µs, loss > 0.01%). Maintain a log of all tests, configuration backups, and cable test results. When a problem arises, this documentation speeds up diagnosis.

Training and Protocols

Ensure that staff responsible for the network understand signal integrity principles. Hold quarterly walkthroughs of the testing procedure. Establish a change-management protocol: any network modification (new device, cable reroute, switch firmware update) must be preceded and followed by a baseline signal integrity test.

Conclusion

Signal integrity testing in AES67 audio networks is a disciplined process that verifies every component from cable to clock. By preparing thoroughly, following a structured step-by-step procedure, and adopting ongoing maintenance best practices, audio professionals can guarantee consistent, glitch-free performance in even the most demanding environments. The investment in proper testing equipment and procedures pays dividends in reduced troubleshooting time, minimal downtime, and superior sound quality—making it an essential part of any professional AoIP installation.

For further reading on AES67 and AoIP testing standards, refer to the Audio Engineering Society standards page and the comprehensive AES67 overview on Wikipedia, which includes references to related testing documents and practical network architecture advice.