In modern audio production and broadcasting, seamless integration across multiple platforms is no longer a luxury—it is a fundamental operational requirement. The proliferation of audio-over-IP (AoIP) technologies has made it possible to transport high-quality audio over standard Ethernet networks, but interoperability between different vendors and systems has historically been a challenge. The AES67 protocol has emerged as a critical standard to solve this problem, enabling high-performance audio over IP networks with guaranteed interoperability. Implementing best practices for cross-platform audio routing using AES67 ensures reliable, low-latency, and scalable audio networks that meet the demands of live production, broadcast, and installed sound environments.

Understanding the AES67 Protocol

AES67, formally known as AES67-2018 (and its recent revision, AES67-2021), is a standard developed by the Audio Engineering Society that defines a set of interoperability requirements for audio-over-IP networks. It specifies how devices from different manufacturers can exchange audio streams using standard network protocols such as RTP (Real-time Transport Protocol) and RTCP (RTP Control Protocol). The standard builds upon existing technologies like SMPTE ST 2110-30 (which uses the same RTP payload format) and Ravenna, ensuring backward compatibility and a clear migration path for broadcasters moving toward IP-based infrastructures.

AES67 is not a complete AoIP system in itself; rather, it is a "profile" that defines common parameters for media clocking, session description, network transport, and synchronization. The key components include:

  • Media Clocking: AES67 mandates a common clock reference using IEEE 1588-2008 Precision Time Protocol (PTP) with a profile based on the SMPTE ST 2059-2 profile. This ensures that all devices in the network share a common time base, allowing sample-accurate alignment of streams.
  • Transport: Audio is transmitted as uncompressed PCM audio over RTP, typically using the L16 (linear 16-bit) coding, though other codecs are allowed. The standard defines packetization rules to keep latency low—typically under 1 millisecond for a single stream.
  • Session Description: AES67 uses the Session Description Protocol (SDP) to describe audio streams. This allows devices to discover and connect to each other automatically, provided they adhere to the same SDP formatting rules.
  • Network Redundancy: While not mandatory, AES67 supports redundant stream configurations using multicast or unicast pairs, often implemented via separate network paths to protect against link failures.

By standardizing these layers, AES67 enables a Yamaha console to route audio to a Dante-equipped stagebox, or a Lawo mixing desk to send programme audio to an AEQ codec—all without vendor lock-in. This flexibility is why AES67 is widely adopted in broadcast, live sound, and fixed-installation environments.

Best Practices for Cross-Platform Audio Routing

Successfully deploying AES67 across a mixed-vendor network requires careful planning and adherence to established engineering principles. The following best practices cover network infrastructure, device configuration, stream management, and monitoring.

1. Network Infrastructure Planning

The foundation of any AoIP system is the network itself. AES67 streams can tolerate a maximum end-to-end latency of a few milliseconds, and any packet loss or jitter can cause audible clicks, dropouts, or synchronization drift. The following guidelines are essential:

  • Bandwidth and Switch Selection: Use managed Gigabit Ethernet (or 10GbE for larger systems) switches with full wire-speed forwarding. For a typical 48-channel AES67 stream at 48 kHz/24-bit, the bandwidth per stream is approximately 69 Mbps (with overhead). Aggregate bandwidth must be calculated based on the number of simultaneous streams. Switches must support IGMP snooping (v2 or v3) to manage multicast traffic efficiently—without it, all multicast streams flood every port, overwhelming receivers.
  • Quality of Service (QoS): Audio traffic must be prioritized over data traffic to avoid jitter. Configure DiffServ (DSCP) markings: AES67 / SMPTE ST 2110 recommends using DSCP 46 (EF) for audio RTP streams, DSCP 34 (AF41) for PTP, and lower values for best-effort data. Switches and routers must honor these markings with strict priority queuing.
  • VLAN Segmentation: Separate all AoIP traffic (including PTP and stream data) onto a dedicated VLAN. This isolates audio from broadcast storms, ARP flooding, and other network anomalies that may originate from IT traffic. Keep the audio VLAN as flat as possible (usually a single Layer 2 domain) to minimize latency and avoid routing hops.
  • Latency Budgeting: Establish a total latency budget for the system (e.g., 5 ms). Include contributions from packetization (typically 1 ms), network switching (sub-millisecond per hop), and receiver buffer. Use switches with cut-through forwarding or very low store-and-forward latency. Avoid oversubscribed uplinks.
  • Redundancy: For critical applications (e.g., live broadcast), deploy parallel networks with separate switches and cabling. AES67 streams can be duplicated and sent to both networks—the receiver uses the audio from the primary network and seamlessly switches to the backup upon failure. This is often implemented using the "stream redundancy" mechanism defined in SMPTE ST 2022-7.

2. Compatibility and Device Configuration

Interoperability across vendors is AES67's raison d'être, but achieving it in practice requires attention to configuration details:

  • PTP Grandmaster Selection: Designate a single PTP grandmaster (GM) on the network. This device—often a dedicated clock generator or a capable audio console—must be the Best Master Clock Algorithm's (BMCA) chosen source. Configure all other devices as PTP slaves. Use the SMPTE ST 2059-2 profile, which defines a sync interval of 1 second and an announcement interval of 2 seconds. Ensure all devices are locked to the same GM; otherwise, audio streams will drift out of sync.
  • IP Addressing: Use static IP addresses or DHCP with reservations for all AoIP devices. Avoid dynamic IP assignment that can change during operation, causing stream disruptions. Subnet masks and default gateways must be consistent. While AES67 supports both unicast and multicast, multicast is preferred for one-to-many routing (e.g., sending a mix to multiple destinations).
  • Firmware and Software Updates: Keep device firmware and network driver software up to date. Many early AES67 implementations had bugs in PTP handling or SDP parsing—continuous updates from vendors fix these issues and improve compatibility. Before upgrading, test in a non-production environment.
  • Supported Sample Rates and Bit Depths: AES67 mandates support for 48 kHz and 96 kHz sample rates, but not all devices support both. Configure all devices to the same sample rate (typically 48 kHz for broadcast). Bit depth is usually 24-bit, but some legacy devices may only handle 16-bit—match the stream format to the lowest common denominator.
  • Clock Domain Handling: When mixing AES67 streams from different sources, ensure they are all referenced to the same PTP domain (usually domain 0). Some systems support multiple domains—using different domains can cause drift unless explicitly managed.

3. Stream Management and Monitoring

Once the network and devices are configured, ongoing stream management is vital to maintain reliability:

  • Session Description Protocol (SDP) Files: Each AES67 stream is defined by an SDP file that includes the multicast address, UDP port numbers, RTP payload type, and clock information. Use consistent file naming conventions and store SDPs in a central location (e.g., a network server or integrated control system). Many control systems (e.g., Q-SYS, Crestron) can import SDP files to automatically discover streams.
  • Source Specific Multicast (SSM): For security and easier troubleshooting, implement Source-Specific Multicast (IGMPv3 with SSM). This ensures that receivers only accept streams from a specific source IP, reducing the risk of rogue devices injecting audio or interfering with legitimate streams.
  • Monitoring Tools: Deploy network monitoring software that can visualize AES67 streams. Tools such as Wireshark (with custom dissectors for SMPTE ST 2110), NMIS, or vendor-specific solutions (e.g., Dante Controller's network view, Lawo's VSM) can show stream existence, packet counts, jitter, and PTP status. Set up alerts for packet loss, grandmaster changes, or PTP offset exceeding 1 µs.
  • Redundant Stream Paths: Where mission-critical audio is involved, send two identical streams—one over Network A and one over Network B—with the receiver performing hitless switching (SMPTE ST 2022-7). This requires that both streams have the same RTP timestamps and sequence numbers; ensure the source duplicates the payload correctly.
  • Documentation: Maintain a current diagram of all streams, including source device, destination device, multicast IP, sample rate, and any redundancy paths. Use a digital spreadsheet or a physical patch-bay-style database. This is invaluable for troubleshooting when a stream drops.

Additional Tips for Optimal Performance

Beyond the core best practices, several advanced techniques and operational habits contribute to a rock-solid AES67 deployment:

  • Thorough Pre-Live Testing: Before any live production, simulate the entire routing scenario in a lab or during off-hours. Verify that all source/destination pairs connect, play audio, and that PTP lock is stable. Test failover scenarios by unplugging network cables or disabling switches. Document any latency differences observed—some devices buffer longer than others.
  • Consistent Clock Synchronization: PTP is the heart of AES67. Use only one grandmaster on the network; if you must have a backup, configure it as a candidate grandmaster but ensure it cannot accidentally take over (adjust the clock class and priority values). Monitor PTP unicast or multicast messages. The network switch's PTP processing (transparent clock or boundary clock) can improve accuracy—enable if available.
  • Network Security: While AoIP networks are often physically isolated, security should not be neglected. Use VLANs to separate audio from IT traffic, implement access control lists (ACLs) to restrict multicast group membership, and consider 802.1X port-based authentication for physical connections. Avoid exposing PTP or stream ports to the corporate network. If remote access is needed, use a VPN-tunneled management VLAN.
  • Staff Training: Train technical operators and engineers not just on the specific audio consoles or routers, but on the principles of AoIP and AES67. They should be able to read an SDP file, interpret PTP offset values, and use a network sniffer to diagnose basic packet loss. Cross-training avoids reliance on a single vendor specialist.
  • Hardware Considerations: Use shielded Cat6a or fiber optic cabling for longer runs. Ensure all network connections are at least 1 Gbps full-duplex. For very large systems (hundreds of streams), consider a spine-leaf architecture to limit the number of multicast hops.

Adhering to these best practices transforms AES67 from a theoretical standard into a practical, reliable tool for cross-platform audio routing. The result is a flexible, scalable audio network that can adapt to changing production needs while maintaining broadcast-grade resilience. As more manufacturers adopt AES67 and its successors (including SMPTE ST 2110 for video and metadata), the case for building a unified IP network becomes even stronger.

For further reading, consult the Audio Engineering Society's official AES67 documents, the IEEE 1588-2008 standard, and practical deployment guides from organizations like the IBC and Sports Video Group. These resources provide deeper technical background and real-world case studies that can inform your own AES67 routing architecture.