Understanding AES67 and IP Audio Networks

Transitioning from traditional analog or digital audio interfaces to AES67-over-IP networks represents a significant shift in how audio is distributed, routed, and managed. AES67 is the Audio Engineering Society’s standard for high-performance audio-over-IP interoperability, allowing devices from different manufacturers to share uncompressed, low-latency audio streams over standard Ethernet networks. Unlike legacy interfaces—such as analog XLR, AES/EBU (AES3), MADI, or ADAT—AES67 does not require dedicated cabling or point-to-point connections. Instead, it leverages existing network infrastructure, enabling flexible routing, longer cable runs (up to 100 meters per segment with copper, much farther with fiber), and easier scaling for large installations such as broadcast studios, live sound venues, houses of worship, and corporate AV systems.

The key advantage of AES67 is its open, vendor-neutral approach. Standards like Dante and RAVENNA also use AES67 as a transport layer, meaning devices from different ecosystems can interoperate on the same network if they support the common AES67 stream format. This interoperability reduces vendor lock-in and future-proofs your investment. However, moving from a familiar analog or digital patchbay environment to an IP-based system requires careful planning—not just in hardware selection but also in network design, latency management, and staff training. This article provides a comprehensive, step-by-step guide to ensure a smooth, low-risk migration.

Assessing Your Current Audio Infrastructure

Before purchasing any new equipment, conduct a thorough audit of your existing audio setup. Document every component: microphones, mixing consoles, signal processors, amplifiers, and recording devices. Note the types of connections used (XLR, TRS, AES3, MADI, etc.), cable lengths, and how signals are routed between rooms or stages. This baseline will help you decide what can be retrofitted with AES67 interfaces, what requires replacement, and what can remain as legacy gear interfaced via converters.

Identifying Upgrade Paths

Many professional audio devices now include built-in AES67/Dante ports or support optional audio-over-IP cards. Check your current equipment’s specifications for AES67 compatibility. For example, modern digital mixing consoles from Yamaha, Allen & Heath, and Behringer often come with Dante expansion slots. If your console lacks native IP support, consider external AES67-to-analog or AES67-to-digital converters. Brands like Focusrite, RME, and Ferrofish offer stage boxes and converters that bridge traditional and IP domains. When evaluating converters, pay close attention to channel count, sample rate support (typically up to 48 kHz or 96 kHz at 24-bit), and latency figures (ideally under 1 millisecond round-trip).

Creating a Phased Migration Roadmap

Do not attempt a rip-and-replace overnight. A phased approach reduces operational risk. Start with a single subsystem—for instance, the front-of-house (FOH) console and monitor mix system—and run it in parallel with your existing analog infrastructure for a few weeks. This allows you to troubleshoot network issues, train operators, and verify the audio quality before expanding to other areas like record feeds, broadcast sends, or auxiliary zones. Your roadmap should include milestones for each phase: initial testing, partial deployment, full integration, and decommissioning of legacy gear.

Network Readiness: The Foundation of Reliable AES67

Reliable AES67 performance depends entirely on your network infrastructure. Unlike data traffic, audio streams are time-sensitive. A misconfigured switch or inadequate bandwidth can cause dropouts, clocking errors, audible clicks, or increased latency. Before connecting any audio devices, ensure your network meets the minimum requirements for AES67.

Choosing the Right Ethernet Switch

Use managed, Gigabit Ethernet switches (or higher for large channel counts). Consumer-grade or unmanaged switches often lack the Quality of Service (QoS) features needed to prioritize audio packets over bulk data. Look for switches that support IEEE 802.1p (Class of Service) and DiffServ to mark and queue AES67 traffic as high priority. Also enable IGMP Snooping (Internet Group Management Protocol) to prevent audio streams from flooding all ports—this is crucial when many multicast streams are used. For critical installations, consider layer-3 switches that support VLANs to segment audio traffic from IT data. Vendors like Netgear (M4250 series), Cisco (Catalyst 1000/3000), and Ubiquiti (UniFi switches with IGMP support) are common choices for audio-over-IP. If your budget allows, dedicated ProAV switches from companies like Luminex or AudioTX are pre-configured for Dante/AES67.

Network Segmentation and VLANs

Even with QoS, mixing audio with heavy data traffic (file transfers, internet browsing, backups) on the same broadcast domain can degrade performance. Create a dedicated VLAN (Virtual Local Area Network) for all AES67 devices and the control network for console software. Use a separate subnet (e.g., 10.10.10.0/24) to isolate audio traffic. If your audio system needs to share a physical network with IT, use trunk ports and VLAN tagging to keep the streams separate. This also improves security—no unauthorized user on the corporate network can accidentally (or intentionally) send traffic to your audio ports.

Cabling and Physical Layer

Use at least Cat5e cable for 100-meter runs; Cat6 or Cat6a is preferred for Gigabit, especially in environments with high electromagnetic interference (EMI). For longer distances or outdoor runs, consider single-mode fiber with SFP+ transceivers. Always terminate cables with high-quality RJ45 connectors that match the cable gauge, and test every link with a cable analyzer to ensure it meets TIA/EIA standards. Avoid daisy-chaining switches—use a star topology with a central switch or a collapsed-core design if you have many endpoints.

Clock Synchronization: PTP and Timing

AES67 relies on Precision Time Protocol (PTPv2, IEEE 1588-2008) to synchronize sample clocks across all devices. Without proper clock distribution, you will experience sample rate mismatches, audio distortion, and dropouts. Designate one device as the Grandmaster Clock (usually the mixing console or a dedicated PTP generator). All other AES67 devices automatically sync to this clock. Ensure your network switches support PTP-aware switching (e.g., one-step or two-step clocking) to minimize clock jitter. Many modern ProAV switches include PTP boundary clock or transparent clock features. If your switches are not PTP-aware, keep the network simple—fewer hops between devices reduces timing errors. Always test the PTP status from multiple devices using software tools like Dante Controller (for Dante networks) or AES67 monitor utilities.

Selecting AES67-Compatible Hardware

Once your network is ready, choose devices that best fit your workflow. The market offers a wide range of AES67-capable products: mixing consoles, stage boxes, amplifiers with IP inputs, speakers with built-in Dante, and software tools for PC-based recording. When evaluating hardware, consider these factors:

Sample Rate and Bit Depth

AES67 supports 24-bit and up to 96 kHz (some implementations support 192 kHz, but that increases bandwidth). For most professional applications, 48 kHz with 24-bit is sufficient and reduces network load. Higher sample rates (96 kHz) may be needed for critical mastering or surround sound. Ensure all devices in your system agree on a common sample rate—mismatched devices will not interoperate.

Latency and Redundancy

Latency is the time it takes for audio to travel from input to output across the network. AES67 specifies a maximum packet time of 1 millisecond (for 48 kHz/24-bit with 48-sample packets). Many devices offer configurable latencies of 0.25, 0.5, 1, or 2 milliseconds. For live sound reinforcement, aim for under 1 ms round-trip; for recording, 2 ms is acceptable. Redundancy options include Dante Redundant (dual Ethernet ports with separate networks) or audio-over-IP solutions using ST 2022-7 seamless protection switching. If your work demands zero downtime (e.g., broadcast), invest in hardware that supports redundant paths.

Interoperability with Existing Gear

Even if you move to AES67, you will likely keep some analog or digital devices. Look for interface converters that offer both AES67 input/output and legacy connections. For example, stage boxes like the Ferrari AES67-4D provide four channels of AES3-balanced digital audio converted to AES67, while analog-to-AES67 gateways from RDL or Soundweb allow microphones and line-level sources to join the IP network. Keep a small analog backup for critical paths until you are fully confident in the IP system.

Implementation: Step-by-Step Deployment

Phase 1: Pilot System in a Controlled Environment

Set up a small test network separate from the production system. Include at least one AES67 source (e.g., a digital mixing console or a stand-alone Dante/AES67 microphone preamp), one receiver (e.g., an amplifier or recorder), and a managed switch. Configure IP addresses (static or DHCP with reserved addresses), enable PTP, and verify that the devices discover each other. Use the device’s software interface—such as Yamaha ConsoleView, Dante Controller (for Dante), or RAVENNA Tools—to route audio and monitor latency. Test for packet loss and clock stability. If you encounter dropouts, check your switch’s IGMP settings and QoS priority.

Phase 2: Gradual Integration into Live Production

Replace one legacy audio path at a time with the AES67 equivalent. For example, connect your console’s AES67 card to a stage box that previously fed analog signals. Keep the analog cable connected as a backup until you confirm the IP route works reliably. During this phase, document every IP endpoint: device name, MAC address, IP, subnet, switch port, and firmware version. This inventory will be invaluable for troubleshooting later.

Phase 3: Network Monitoring and Optimization

Use network monitoring tools—like PRTG Network Monitor or Wireshark—to track bandwidth usage, packet loss, and PTP delays. Most AES67 devices also provide web interfaces with diagnostic logs. Create alerts for unusually high CPU loads on switches or excessive multicast traffic. If you notice increasing latency, check for network loops or misconfigured broadcast storms. Consider enabling flow control on switches as a safety measure, but be aware that some AV-over-IP experts recommend disabling it to avoid head-of-line blocking.

Phase 4: Full Transition and Legacy Decommissioning

Once all critical audio paths are routed over AES67 and the system has run without issues for at least two weeks, you can safely remove the analog cables and decommission legacy hardware. Archive the documentation and keep backup configurations of switches and devices. If you ever need to revert (e.g., during a network failure), having a documented analog fallback plan is prudent.

Configuring AES67 Devices: Key Settings

IP Addressing and Discovery

By default, many IP audio devices obtain an IP via DHCP. For critical systems, assign static IP addresses reserved outside the DHCP range to prevent address changes after a power cycle. Use consistent subnetting (e.g., 10.0.0.0/24). Enable Session Announcement Protocol (SAP) or mDNS (depending on the ecosystem) so that AES67 streams are advertised across the network. In Dante Controller, you can see all streams appearing under the “Receive” tab.

Stream Configuration

Each AES67 stream is essentially a multicast flow defined by source address, destination multicast address (usually within 239.x.x.x range), port number, and payload format. When configuring, ensure that all endpoints use the same packet time (e.g., 1 ms) and sample format. Avoid using the default “mono” stream definition if you need stereo; create a stereo stream by declaring two channels in the control software. Set appropriate Differentiated Services Code Point (DSCP) values—typically 46 (Expedited Forwarding) for audio and 34 (Assured Forwarding) for control data. This marking lets switches apply the correct priority queue.

Clock and Redundancy Settings

On the Grandmaster clock device, select a stable reference source—internal crystal, Word Clock input, or AES67 PTP. If your system includes devices from different manufacturers, verify they all use the same PTP domain number (default is 0 for AES67). For redundant networks, configure Primary and Secondary interfaces on each device using separate subnets and different switch stacks. Some devices allow seamless failover; test this by pulling a network cable during an active stream—there should be no audio glitch if redundancy is properly implemented.

Best Practices for a Smooth Migration

Training and Documentation

Even the best hardware can be undermined by operator confusion. Schedule training sessions for engineers, technicians, and operators covering: how to connect AES67 devices to the network, how to use control software (Dante Controller, RAVENNA tools, or manufacturer-specific apps), how to interpret PTP status, and how to perform basic troubleshooting (e.g., checking VLAN assignments, testing cable continuity). Create a quick-reference guide with network diagrams, IP addresses, and normal operational indicators (e.g., green LEDs on network ports, PTP sync status). This documentation is invaluable during live events when time is critical.

Labeling and Organization

Label all Ethernet cables clearly at both ends. Use color-coding for different VLANs (e.g., red for audio VLAN, blue for control VLAN). Mark device panels with their IP address and console designation. In the rack, maintain neat cable management to avoid accidental pulls or EMI coupling from power cables. Use cable lengths no longer than necessary to reduce excess slack.

Testing and Quality Assurance

Before any major event, run a full system check: ping every device, verify PTP locked status, monitor latency with a latency measurement tool (e.g., Audio Precision or simply a phase test tone), and listen to program material for artifacts. Check that all backup and redundancy paths work. Document the expected stream topology—for example, which console sends which bus to which DSP matrix—and confirm that the network can handle worst-case channel counts.

Troubleshooting Common AES67 Migration Issues

Even with careful planning, problems can arise. Here are typical pitfalls and their solutions:

Audio Dropouts or Pops

  • Cause: Network congestion or QoS misconfiguration. Other traffic (like large file transfers) is competing for bandwidth.
    Solution: Move non-audio traffic to a separate VLAN. Verify the DSCP marks on AES67 streams and That your switch priority queue is configured for Expedited Forwarding.
  • Cause: PTP clock instability. The Grandmaster clock is drifting or network jitter exceeds 1 ms.
    Solution: Check PTP cable quality and switch PTP support. Reduce the number of hops. Update firmware to improve PTP implementation.
  • Cause: Duplicate IP addresses on the network.
    Solution: Use static IPs with ARP inspection or DHCP reservation. Ping each new device before assigning it.

No Audio After Configuration

  • Cause: Stream routing not enabled in control software. The transmitter is not sending on the correct multicast address or port.
    Solution: In Dante Controller, ensure the stream is subscribed. In AES67 raw mode, verify the SDP (Session Description Protocol) file is correctly imported to the receiver.
  • Cause: IGMP snooping not enabled or incorrectly configured.
    Solution: Enable IGMP snooping on all switches. Ensure the switch knows the multicast group membership—if a receiver hasn’t sent an IGMP join, the stream may not be forwarded.

High Latency

  • Cause: Packet time set too large (e.g., 4 ms vs 0.25 ms) to accommodate long cable runs or many hops.
    Solution: Reduce packet time on both transmitter and receiver. Use a direct gigabit connection between endpoints if avoiding switches.
  • Cause: Switches are not set for cut-through switching? Most AES67 equipment uses store-and-forward switches, which add latency. Use switches designed for AV with low latency characteristics.

Conclusion: Future-Proofing Your Audio Workflow

Transitioning to AES67 IP networks is not merely a technology upgrade—it is a strategic move toward greater flexibility, scalability, and interoperability. By following a phased approach, building robust network infrastructure, and training your team thoroughly, you can avoid the common pitfalls that plague first-time adopters. The result is a system that supports uncompressed, low-latency audio across large distances, with the ease of re-routing signals on a computer screen instead of pulling physical cables.

To dive deeper into AES67, explore the official AES67 standard document and the Audinate Dante Training and Certification program, which covers AES67 fundamentals. For network equipment selection, refer to the Netgear ProAV switch series and Luminex network solutions for preconfigured switches. As your IP audio knowledge grows, you’ll find that AES67 becomes the backbone of a modern, future-proof audio infrastructure.