Conducting a thorough AES67 network audit and optimization is essential for any professional audio environment that relies on audio‑over‑IP interoperability. The AES67 standard, defined by the Audio Engineering Society, enables different audio‑over‑IP systems—such as Dante, RAVENNA, Livewire, and Q‑LAN—to exchange high‑quality, low‑latency audio streams over standard Ethernet networks. Without a properly maintained network, even the most capable audio devices can suffer from dropouts, audible clicks, delayed streams, or complete failure. This expanded guide walks you through the entire audit and optimization process, from initial preparation to long‑term maintenance, ensuring your AES67 network delivers reliable, broadcast‑grade performance.

Understanding AES67 and Its Importance

AES67 was published in 2013 as a standard for transporting uncompressed, linear PCM audio over IP networks. It specifies critical parameters such as sampling rates (48 kHz), bit depth (16 or 24 bits), packet size (1 ms by default), and synchronization via IEEE 1588 Precision Time Protocol (PTP). The standard ensures that any compliant device from any manufacturer can receive and transmit audio streams without proprietary gateways or transcoding.

In practice, AES67 is the glue that binds heterogeneous audio networks. A studio may combine a Dante‑based mixing console, RAVENNA‑equipped amplifiers, and a Livewire intercom system; AES67 guarantees they all speak the same “language” at the transport level. This interoperability is particularly valuable in broadcast facilities, performance venues, corporate campuses, and houses of worship where mixed vendor ecosystems are common.

Network performance directly affects audio quality. High latency introduces delay that can disrupt live performances or cause lip‑sync errors in broadcast. Packet loss results in audible dropouts or glitches. Jitter (variation in packet arrival times) degrades the ability of receivers to reconstruct the original waveform. A proper audit identifies exactly where these problems originate—whether in switches, cabling, clock sources, or traffic engineering—and provides a roadmap for optimization.

Preparing for the Audit

Thorough preparation saves time during the audit and helps uncover issues that might otherwise be missed. Begin by collecting all relevant network documentation, including topology diagrams, device configurations, and current performance metrics. Document the make, model, firmware version, and role of every network switch, router, and managed endpoint on the audio subnet. If you are dealing with a large facility, also map out which physical ports carry AES67 traffic and which carry data, management, or video traffic.

Verify that every network switch in the audio path supports essential features: IGMP snooping, Quality of Service (QoS) with strict priority or expedited forwarding, VLANs, and a low‑latency switching fabric. Many consumer or “unmanaged” switches lack these features and should be replaced before any formal audit. Also confirm that all devices are running the latest firmware, as vendors frequently release patches that improve PTP clock stability or reduce jitter.

Identify critical audio streams and their endpoints. For example, a broadcast console sending program audio to a video encoder, or a microphone preamplifier feeding a DSP core. List the source IP addresses, multicast group addresses, and destination IPs for each stream. This information is essential when analyzing traffic patterns later.

Assemble your toolset. Essential tools include:

  • Network protocol analyser – Wireshark is the de facto standard, with built‑in dissectors for RTP, PTP, and multicast.
  • Dedicated audio‑over‑IP analyser – tools like QSC Q‑Sys or specialized hardware from Lawo or Yamaha can automatically detect AES67 stream health.
  • PTP analysis tools – ptp4l with logging, or dedicated products like Calnex Sentinel.
  • Switch monitoring software – SNMP‑based monitors (PRTG, SolarWinds) can track interface errors, discards, and bandwidth utilisation.
  • Cable tester – to verify that cabling meets Category 5e or better standards.

Key Preparation Steps

  • Update and backup all network device configurations.
  • Create a baseline traffic capture during a low‑activity period to compare against peak usage.
  • Coordinate with facility management to schedule the audit during off‑hours if live traffic cannot be disrupted.
  • Document current Quality of Service (QoS) markings – AES67 should use DSCP EF (46) for RTP audio, CS7 (56) for PTP clock, and CS0 (0) for best effort.

Key Performance Metrics for AES67

Before diving into the audit, understand the specific metrics that define a healthy AES67 network:

  • Latency (one‑way delay): AES67 targets less than 1 ms of network latency per hop. End‑to‑end latency should not exceed 2 ms for local networks; higher values indicate excessive buffering or switch congestion.
  • Jitter: The variation in packet inter‑arrival time. Acceptable jitter for AES67 receivers is typically under 100 µs. Jitter above 500 µs can cause buffer underruns or overflows, leading to audio corruption.
  • Packet loss: Should be zero for all AES67 streams. Even 0.1% packet loss results in noticeable clicks.
  • Clock synchronisation (PTP): The Grandmaster clock must be stable within ±10 ns of the reference frequency. All slave clocks should lock to within 1 µs of the master. Large offset or drift indicates PTP path asymmetry or overloaded switches.
  • Bandwidth utilisation: AES67 streams consume roughly 1.3 Mbps per channel (48 kHz, 24 bit). Keep total multicast bandwidth below 70% of link capacity to allow for bursts and control traffic.

These metrics form the basis of your audit. Any deviation from acceptable thresholds must be investigated and corrected.

Conducting the Audit: Step‑by‑Step

Begin the physical audit by verifying cable integrity and connector termination. Loose connectors or incorrectly terminated Cat6 cables can cause retransmissions that inflate latency. Use a cable tester to certify every link carrying AES67 traffic.

Next, capture network traffic using Wireshark at several critical points: at the source device, at a receiver, and on the switch backbone. Filter for the specific multicast groups used by your audio streams. Examine the following:

  • RTP packet arrival times: Look for gaps or bunches. A steady 1‑ms packet spacing is ideal. If packets arrive in clusters, switches may be queuing them incorrectly.
  • PTP messages: Wireshark decodes Sync, Follow_Up, Delay_Req, and Delay_Resp messages. Check that the Grandmaster’s timestamp is consistent and that the measured delay is symmetric. Asymmetry greater than 50 µs can degrade synchronisation.
  • QoS markings: Confirm that DSCP EF is set on all RTP packets and that intermediate switches are not stripping or re‑marking them.

Use the switch’s command‑line interface (CLI) or web GUI to inspect interface counters. Look for CRC errors, alignment errors, runts, giants, and discards. A non‑zero count on any of these suggests a physical layer problem. Also check multicast group membership with show ip igmp groups to ensure that receivers are requesting and being served the correct audio streams.

Monitor bandwidth utilisation during peak usage. Many network management tools can plot utilisation per port over several hours. Identify any port that exceeds 70% utilisation during audio transmission. High utilisation often forces packets into output queues, increasing jitter.

Assessing Network Performance

  • Measure latency and jitter for each audio stream using Dante Controller’s latency tab or Wireshark’s RTP analysis.
  • Identify any packet loss by comparing the RTP sequence numbers – missing numbers equal lost packets.
  • Verify that all switches respect the IEEE 802.1p priority of AES67 traffic (priority 5). Some switches require manual mapping of DSCP to COS.
  • Check for network congestion during peak usage by reviewing switch queue depths – queues that are perpetually full indicate oversubscription.

Common Issues Found During Audits

Experienced audio engineers and network administrators encounter several recurring problems when auditing AES67 networks:

  • Incorrect PTP configuration: Multiple Grandmasters, or a Grandmaster selected from a device with a drifting oscillator. Ensure exactly one Grandmaster is elected, ideally a dedicated PTP‑capable switch or appliance.
  • QoS misconfiguration: Audio packets marked as best effort (DSCP 0) become queued behind large file transfers or broadcast storms. Verify end‑to‑end QoS forwarding.
  • VLAN mismatches: Audio VLANs not properly trunked across switches, or receiver interfaces placed in the wrong VLAN.
  • Multicast IGMP issues: IGMP snooping disabled or running in “querier” mode on multiple switches causing duplicate stream copies. Only one IGMP querier should exist per VLAN.
  • Switch with excessive buffer depth: Some enterprise switches buffer to reduce packet loss, but deep buffers add latency that exceeds AES67’s 1‑ms hop limit. Look for switches with “store‑and‑forward” latency below 5 µs.
  • Clock drift due to asymmetrical network paths: PTP relies on symmetrical delays. If the network path from Master to Slave differs from Slave to Master (e.g., due to different switch port types), synchronisation degrades.

Each of these issues can be diagnosed through careful analysis of Wireshark captures and switch logs, and then corrected with configuration changes or hardware upgrades.

Optimization Strategies

After identifying problems, implement targeted optimizations. The following strategies address the most common root causes of poor AES67 performance.

Quality of Service (QoS) Deep Dive

Configure every switch along the audio path with the same QoS policy. Define class‑maps that match DSCP EF and CS7, and assign these to a strict‑priority queue (e.g., queue 4 on Cisco switches). Place all other traffic in lower queues. Ensure that shaping or policing does not apply to the priority queue—these actions can reintroduce delay. Test the policy with a known traffic generator to verify that audio packets are never delayed behind control traffic.

VLAN Segmentation for Audio Isolation

Place all AES67 audio devices in a dedicated VLAN separate from data, management, and public network traffic. This prevents broadcast storms from non‑audio devices from affecting audio performance. Use a single VLAN for PTP and audio to keep clock domains simple. Configure the switch’s IGMP snooping to prune multicast streams only to ports that require them, reducing load on every switch in the network.

Clock Distribution (PTP) Optimisation

Designate a single Grandmaster clock, ideally a Boundary Clock that resides in a network switch capable of PTP‑aware transit (IEEE 1588‑2008 TC or BC). Avoid using audio devices (like a mixing console) as the Grandmaster unless they have been certified for PTP stability. Use only one‑step or two‑step clock mechanisms consistently across the network. Monitor the GM’s holdover capability—if the GM loses GPS reference, it should maintain sub‑1 µs accuracy for at least four hours.

Switch Selection and Topology

Not all “gigabit” switches are suitable for AES67. Prefer switches with cut‑through or fabric‑based switching latency under 1 µs. Avoid switches that impose buffer‑bloat. A typical AES67 network uses a star topology with a central core switch; daisy‑chaining more than three switches introduces excess latency and single points of failure. Where redundancy is required (e.g., broadcast studios), deploy redundant cores with Link Aggregation Groups (LAGs) or Rapid Spanning Tree Protocol (RSTP) tuned for sub‑second convergence.

Multicast Avoidance in Small Deployments

For networks with fewer than 10 audio streams, consider using unicast streams instead of multicast. Unicast eliminates IGMP overhead and potential snooping bugs. However, this consumes more switch resources if many receivers need the same audio. Evaluate the trade‑off based on your facility size.

Firmware and Driver Updates

Check the firmware of every switch, audio device, and interface card. Vendors often release updates to improve PTP stack stability, reduce jitter, or add support for newer versions of AES67. The same applies to network drivers on PC‑based audio nodes. An overlooked update can fix the root cause of intermittent audio dropouts.

Maintaining a Healthy AES67 Network

An audit is not a one‑time event. Plan for regular quarterly or semi‑annual audits to catch configuration drift or hardware ageing. Automate where possible: use SNMP to track interface errors, and deploy syslog to capture switch PTP log messages. Many network monitoring platforms (like PRTG or Observium) can trigger alerts when jitter exceeds 50 µs or when a stream loses sync.

Keep a log of every configuration change, firmware update, and cable replacement. When new devices are added to the network, verify their AES67 compliance by checking the AES67 matrix on the AES Standards page. Also stay current with updates to AES67–R (the revised version) and related standards like SMPTE ST 2110‑30 for broadcast video integration.

Train audio engineers and IT staff on basic network troubleshooting for AES67. They should know how to launch a Wireshark capture, filter for RTP, and interpret simple metrics. Field‑replaceable network components—like an extra switch or a set of SFP modules—should be kept in stock to minimise downtime during failure.

Conclusion

A successful AES67 network audit and ongoing optimization are essential for achieving reliable, high‑quality audio streaming in professional environments. By understanding the standard, preparing thoroughly, identifying key performance metrics, and systematically addressing the most common pitfalls, you can eliminate dropouts, reduce latency, and maintain tight synchronisation across all your audio‑over‑IP devices. The effort pays off every day in flawless live broadcasts, seamless intercom communications, and studio recording sessions free from network‑induced artifacts. As audio‑over‑IP ecosystems continue to expand, disciplined network audits and optimizations will remain the bedrock of operational excellence.