Setting up an AES67-compliant audio network is a foundational task for any professional audio environment that requires high-quality, low-latency, and interoperable audio streaming across devices from different manufacturers. Whether you are building a broadcast studio, live event system, or a fixed installation, following a structured approach ensures your network delivers reliable performance. This guide expands the core steps with practical details, configuration examples, and real-world considerations to help you build a robust AES67 network from the ground up.

Understanding AES67 and Its Role in Modern Audio

AES67 is a standard published by the Audio Engineering Society that specifies the transport, synchronization, and stream format requirements for interoperable audio-over-IP (AoIP). It does not dictate the physical layer or control protocols but defines a common “language” that devices from different ecosystems—such as Dante, RAVENNA, Q-LAN, and Livewire—can use to communicate. Key technical elements include:

  • Uncompressed linear PCM audio at common sample rates (44.1, 48, 96 kHz) and bit depths (16, 20, 24).
  • RTP transport over IPv4 multicast or unicast, typically using UDP.
  • PTPv2 (IEEE 1588-2008) for precise clock synchronization.
  • Session Description Protocol (SDP) to advertise and discover streams.
  • Support for up to eight channels per stream in a single RTP session.

AES67 is not a full control protocol—it handles only the media transport and synchronization layers. This means you still need a management layer (such as Dante Controller or RAVENNA’s web interfaces) for routing and configuration, but AES67 guarantees that the audio packets themselves are universally accepted.

Prerequisites for a Successful Deployment

Before touching any device, ensure your infrastructure meets the baseline requirements. The following checklist covers hardware, software, and knowledge prerequisites:

  • Network switches capable of IGMP snooping, DiffServ QoS (DSCP), and jumbo frames (MTU 9000 recommended). Managed switches are strongly preferred for VLAN segmentation and traffic monitoring.
  • Ethernet cabling that is at least Cat5e for 100 Mbps links or Cat6 for 1 Gbps. Shielded cabling (STP) helps in electrically noisy environments.
  • At least one IEEE 1588-2008 compatible grandmaster clock (standalone PTP server, or a switch acting as boundary clock, or a capable audio device).
  • AES67-compatible devices – mixers, microphone preamps, amplifiers, encoders/decoders. Check manufacturer specs for AES67 support and firmware version.
  • Dedicated VLAN for AoIP traffic to separate it from data traffic (optional but highly recommended for large networks).
  • Benchmarking tools: Wireshark for packet inspection, bandwidth calculators, and latency measurement utilities.

If you are working with existing IT infrastructure, verify that the switches do not have energy-saving features (Energy Efficient Ethernet) that could introduce clock jitter. Disable spanning tree on ports that directly connect audio devices (use PortFast or similar), but keep it on inter-switch links.

Step 1: Network Topology and Bandwidth Planning

Mapping Your Audio Flow

Draw a physical topology showing every AES67 device and its switch port. Identify which devices will be sources (transmitters) and which will be sinks (receivers). Note the redundancy requirements: do you need redundant PTP grandmasters, or a secondary network path? For live events, avoid daisy-chaining switches that carry audio and control on the same uplink without QoS.

Bandwidth Calculation

Each AES67 unicast or multicast stream consumes predictable bandwidth. A single stereo channel (48 kHz, 24-bit, 2 channels) in one RTP packet requires approximately 2.4 Mbps. For multicast streams, this bandwidth is replicated on every switch port that has subscribers. Use this formula for rough planning:

Stream bitrate = (sample_rate × bit_depth × channels) + overhead (~20% for RTP/IP headers).

For 64 channels at 48 kHz/24-bit (uncompressed), the total gross bitrate is roughly 150 Mbps. Ensure your switch uplinks and backbone ports are rated significantly higher (1 Gbps minimum, 10 Gbps for large installations). Also consider that PTP synchronization packets are small (approx. 100 bytes each) but require low jitter; they should be given highest priority.

Step 2: Configuring Network Switches for AES67 Traffic

Quality of Service (QoS)

QoS ensures that time-sensitive audio packets are not delayed by bursts of data traffic. Configure the following DSCP values on your switches (as per AES67 recommendation):

  • PTP event messages: DSCP 56 (CS7) – highest priority, low latency.
  • Audio RTP packets: DSCP 46 (EF) – expedited forwarding.
  • Other control traffic (mDNS, SAP): DSCP 0 (default) or CS1.

Use trust DSCP mode on access ports and set the switch to rewrite DSCP to the correct values if devices send incorrect markings. Apply a strict-priority scheduling policy for queues 3 (EF) and 4 (CS7), and set a policer for non-audio traffic to prevent starvation of lower queues.

Multicast Handling

AES67 uses multicast by default (destination addresses in the 239.x.x.x range). Enable IGMP snooping on all switches to limit multicast traffic only to ports that have requested it. Configure IGMP querier function on one switch in each VLAN (or use PIM if you have Layer 3 routing). Without snooping, multicast floods to all ports and can overwhelm 100 Mbps links.

VLANs and Jumbo Frames

Dedicate a separate VLAN for AoIP traffic. This isolates audio from data broadcasts, simplifies QoS, and prevents DHCP/ARP storms from affecting real-time streams. Set the MTU to 9000 bytes on all switch interfaces and device NICs that support jumbo frames. AES67 packets can be up to 1470 bytes payload (standard UDP/IP), but larger MTU reduces overhead and jitter.

Step 3: Precision Time Protocol (PTP) Synchronization

Choosing the Grandmaster Clock

The Grandmaster (GM) is the most stable clock in your network. Options include:

  • Dedicated PTP grandmaster (e.g., Meinberg, EndRun) with GPS or atomic clock reference.
  • Capable AES67 device that supports grandmaster role (e.g., some RAVENNA interfaces).
  • Switch with built-in boundary clock (e.g., Cisco Catalyst 3560-CX or Netgear M4300 series).

For most professional audio networks, a GPS-disciplined grandmaster offers the best long-term stability (< 1 µs accuracy over 24 hours). If you cannot use GPS, at least ensure the grandmaster uses a TCXO or OCXO oscillator and is connected via PTP over Ethernet (no Wi-Fi or unnecessary bridges).

Configuring PTP Profiles

AES67 requires the use of the “AES67-2015” PTP profile, which is based on IEEE 1588-2008 (PTPv2) with specific settings:

  • Sync interval: 1 packet per second (logSyncInterval = 0).
  • Announce interval: 1 second.
  • Delay request interval: 1 second.
  • Domain number: 0 (by default, but can be changed if multiple clock domains exist).
  • One-step clock recommended (two-step is allowed but adds asymmetry).

Configure all devices (including the grandmaster) to use the same domain. After setting the grandmaster, verify that ordinary clocks (slaves) lock to it. Most AES67 devices show PTP status in their web interface or front panel. Check for offsets less than 100 ns (target: under 30 ns) and no repeated “Uncalibrated” state.

Boundary Clocks and Transparent Clocks

In large networks spanning multiple switches, use boundary clocks (BC) to prevent accumulation of packet delay variation. A boundary clock terminates PTP on one port and re-generates it on others, resetting the accumulation. Some managed switches support native BC mode (e.g., Cisco “ptp” commands). If not, you may need to use a dedicated PTP-aware switch or keep the network diameter small (≤ 3 hops).

Step 4: Connecting and Configuring AES67 Devices

IP Address Assignment and Network Discovery

Assign static IP addresses or configure DHCP with reservations. Avoid using addresses that overlap with other VLANs. AES67 devices typically advertise their streams using SAP (Session Announcement Protocol) or mDNS (Multicast DNS) over the same VLAN. Ensure that IGMP snooping does not block these announcements—they use specific multicast groups (224.0.0.201 for SAP, 224.0.0.251 for mDNS).

Enabling AES67 Mode on Each Device

Most AoIP devices have a compatibility mode switch in their administration interface. For example, on a Dante device, enabling AES67 requires switching from Dante’s native timing to PTP slave mode and setting the correct stream format. On a RAVENNA device, AES67 is native but may require matching sample rate and encoding. Follow the manufacturer’s “AES67 Setup Guide” carefully, as incorrect PCM encoding can cause silence or white noise.

Stream Subscription and Routing

Since AES67 lacks a standardized control protocol, you must use the device vendor’s management tool to create subscriptions (e.g., Dante Controller for Audinate devices, RAVENNA Manager for AES67-compatible equipment). In the tool, choose the source stream (identified by its SDP information) and assign it to a sink input. Keep naming conventions simple to avoid confusion during troubleshooting.

Step 5: Testing and Validation

Basic Connectivity Check

Use ping to verify that all devices can reach each other and the grandmaster. If some devices are on a different subnet, ensure routing is configured and that multicast is forwarded (PIM sparse mode or IGMP proxy).

Clock Synchronization Audit

From a device’s web interface or SNMP, check the PTP offset. A healthy system shows offsets below 500 ns. If offsets are large, investigate the grandmaster’s stability and the network path. Try plugging the grandmaster directly into the switch that hosts the most clock-sensitive devices.

Audio Streaming Test

Send a test tone (e.g., 1 kHz at -20 dBFS) from a source device to a sink. Use an oscilloscope or metering software to confirm that the audio arrives with correct level and no dropouts. Run the test for 30 minutes while generating random data traffic on a different VLAN to stress the QoS configuration.

Network Monitoring

Deploy tools like Wireshark to capture RTP and PTP packets. Filter for PTPv2 (udp.port == 319) and check the sync intervals. For RTP, look for sequence numbers—gaps indicate packet loss. Also monitor the switch CPU load during heavy multicast; if IGMP snooping is misconfigured, the switch may miss membership reports.

Troubleshooting Common Issues

ProblemLikely CauseSolution
Audio dropouts or clicksClock drift or packet loss due to QoS misconfigurationVerify PTP offsets; check DSCP markings; confirm no switch port is oversubscribed.
No audio receivedIncorrect multicast group or SDP mismatchCompare source and sink SDP for sample rate, encoding, and IP address.
High latency (> 2 ms)Fragmentation or buffer bloatEnable jumbo frames; reduce PTP sync interval; disable energy-efficient ethernet.
PTP slave does not lockWrong domain or one-step/two-step mismatchSet all devices to domain 0; ensure grandmaster is one-step if slaves expect one-step.

Advanced Considerations: Redundancy and Integration

For mission-critical applications, implement redundant grandmasters using the IEEE 1588 Best Master Clock Algorithm (BMCA). Two grandmasters on the same domain—one as Active, one as Hot Standby—will auto-failover. Additionally, configure redundant network paths with link aggregation (LACP) or use two independent switch fabrics (primary and backup VLANs) with multicast forwarding disabled on the backup until needed.

AES67 interoperates with Dante via Audinate’s AES67 compatibility, with RAVENNA natively, and with many other AoIP systems. When integrating, treat each system as a separate VLAN, then use an AES67 bridge device (e.g., a LavryQuattra or a Merging Hapi) to convert between protocols. Ensure the bridge is PTP-slave to the same grandmaster as the rest of the network.

For more detailed specifications, consult the AES67 standard (AES67-2015) and the IEEE 1588-2008 standard. Additional best practices for network design are documented in the Audinate network design guide.

Conclusion

Building an AES67-compliant audio network requires careful planning of topology, switch configuration, synchronization, and device integration. By following the steps outlined—starting with bandwidth calculations, ensuring proper QoS and multicast handling, deploying a stable PTP grandmaster, and methodically testing each layer—you can achieve a system that delivers low-latency, glitch-free audio across a variety of equipment. Regular firmware updates and ongoing monitoring will keep the network performing reliably as your audio infrastructure evolves.