AES67 is now the standard for audio networking in broadcast and live production. But setting it up for the first time — especially bridging it with existing analog or AES3 gear — trips up even experienced engineers. This guide walks through every step, from switch configuration to signal verification, so you can have a working AES67 link in under 30 minutes.

1. What You Need Before You Start

AES67 runs over standard IP infrastructure, but it has specific requirements that consumer-grade equipment cannot meet:

  • Managed PoE network switch — Must support IEEE 802.1Q VLANs and IGMP snooping. Tested options: Cisco SG350 series, Netgear M4250, Luminex GigaCore. Unmanaged switches flood multicast to every port and will corrupt the audio stream.
  • AES67 converter or interface — Converts between AES67 IP streams and physical audio formats (AES3/XLR, MADI, or analog). The SUPERCAN AES67 Converter handles AES3 ↔ AES67 bridging and optional Dante/RAVENNA interoperability in a single rackmount unit.
  • PTPv2 grandmaster clock — AES67 requires IEEE 1588-2008 Precision Time Protocol version 2 for sub-microsecond clock synchronization. Many managed switches include a PTP boundary clock mode; some AES67 devices have a built-in grandmaster.
  • Ethernet cable (Cat5e minimum, Cat6 recommended) — Keep each run under 100m. For longer distances, use fiber with media converters.
  • Audio source and destination — Any device that outputs or accepts AES3 (XLR balanced), MADI, or AES67 streams.

2. Plan Your Network Topology First

Sketch the signal flow before connecting anything:

  • Isolate the audio network. Keep AES67 traffic on a dedicated VLAN or a separate physical switch. Continuous multicast audio will saturate a shared data network.
  • Designate a PTPv2 grandmaster. In small systems (2–4 devices), AES67 units elect a grandmaster automatically via the Best Master Clock Algorithm (BMCA). In larger systems, use a dedicated grandmaster for stability.
  • Assign fixed IP addresses. Use static IPs or DHCP reservations. Dynamic addresses that change mid-show break multicast routing and cause dropouts.

3. Configure the Network Switch

Three switch settings are critical — most first-time failures trace back to skipping these:

3.1 Enable IGMP Snooping

AES67 audio is sent as multicast UDP. Without IGMP snooping, the switch copies every audio packet to every port, overwhelming endpoints not subscribed to that stream. Enable IGMP snooping on the audio VLAN.

3.2 Enable PTP Boundary Clock Mode

Configure the switch as a PTP boundary clock if supported. This absorbs timestamp errors across cable runs and star topologies. Use the AES67 PTP profile or IEEE 1588 default profile — not the “power” (ITU-T G.8275) profile used in telecom.

3.3 Set QoS / DSCP Marking

Mark AES67 RTP packets with DSCP EF (Expedited Forwarding, decimal 46) to prioritize audio over other IP traffic. Most AES67 devices tag packets automatically; confirm the switch honors DSCP values.

4. Connect and Configure Your AES67 Converter

Using the SUPERCAN AES67 Converter as a reference — configuration steps are similar across brands:

4.1 Physical Connection

  • Plug the converter’s Ethernet port into the audio switch.
  • Connect AES3 XLR cables between the converter and your console or stage box.
  • Power on the unit (100–240V AC auto-ranging).

4.2 Open the Web Interface

From a laptop on the same network, navigate to the converter’s IP address (shown on the front-panel display or in your switch’s DHCP table). Check two things immediately:

  • PTP status — Must show “PTP Locked.” If it shows unlocked, check IGMP snooping and grandmaster reachability before proceeding.
  • Stream list — Shows active TX (transmit) and RX (receive) streams. Should be empty on first setup.

4.3 Create a Transmit Stream

To send audio from the converter’s AES3 input into the AES67 network:

  1. Click Add TX Stream.
  2. Set multicast address (e.g., 239.69.0.1 — the 239.69.x.x range is reserved for AES67 per the standard).
  3. Set sample rate: 48 kHz for live sound and broadcast (match your console’s wordclock).
  4. Set bit depth: 24-bit (AES67 standard).
  5. Set packet time: 1 ms (AES67 standard; lower values reduce latency but increase network load).
  6. Assign input channels (e.g., AES3 Ch 1–8 → Stream Ch 1–8).
  7. Click Save. The TX stream appears in the Active Streams list with a green indicator.

4.4 Subscribe to a Receive Stream

To receive an AES67 stream from the network into the converter’s AES3 outputs:

  1. Click Add RX Stream.
  2. Enter the source device’s multicast address and UDP port (typically 5004).
  3. The converter joins the multicast group via IGMP and begins receiving within 1–2 seconds.
  4. Map the incoming stream channels to AES3 output channels.

5. Verify the Signal Chain

Confirm audio is flowing end-to-end before going live:

  • Input metering — On the source device, confirm AES3 input shows signal (not silence or clip).
  • Packet statistics — In the converter’s web interface, check RX stream statistics. Target: Packet Loss: 0. Any loss indicates switch misconfiguration or network congestion.
  • Listen check — Route the AES67 output to a monitor amp or a spare console channel. Verify correct channel assignment, polarity, and no artifacts.
  • Latency check — AES67 at 1ms packet time adds 2–5ms of network latency end-to-end. Total round-trip (AES3 in → AES67 network → AES3 out) is typically 5–10ms, within the tolerance of live production workflows.

6. Troubleshooting Reference

Symptom Likely Cause Fix
No audio, PTP unlocked Grandmaster unreachable Check IGMP snooping; verify grandmaster IP is reachable by ping from the converter
Intermittent dropouts Packet loss / switch congestion Enable QoS DSCP EF on audio VLAN; check for bandwidth saturation on uplinks
Hum on analog outputs downstream Ground loop via AES3/XLR cables Use an XLR isolation transformer on the affected output leg to break the ground loop
Channels misrouted Wrong channel offset in RX stream mapping Re-check TX and RX channel assignment in the web interface; channels are 1-indexed
Latency exceeds 20ms Excessive PTP wander or large playout buffer Reduce the converter’s playout buffer setting; use a dedicated PTP grandmaster clock
AES67 incompatible with Dante device Different clock domains Enable AES67 mode in Dante Controller; use SUPERCAN converter as a bridge between domains

7. Scaling to Multi-Device Systems

Once a basic two-device AES67 link is working, the same infrastructure scales without redesign:

  • Add devices incrementally. Each new AES67 device joins existing multicast groups. The switch handles traffic forwarding via IGMP — no reconfiguration of existing devices required.
  • Bridge to Dante or RAVENNA. The SUPERCAN AES67 Converter supports Dante and RAVENNA bridging, connecting AES67 endpoints into an existing Dante network. For a deeper protocol comparison, see the AES3 vs AES67 guide.
  • Add redundancy. AES67 supports hitless stream redundancy per SMPTE ST 2022-7: two parallel network paths, seamless failover. Wire both through separate physical switches for full protection.

Frequently Asked Questions

Do I need a special switch for AES67?

Yes. A managed switch with IGMP snooping and PTP-aware (boundary clock) forwarding is required. Unmanaged switches and consumer routers flood multicast to all ports and cannot participate in PTPv2 synchronization — both will cause dropouts and clock drift.

Can AES67 and Dante coexist on the same physical network?

Yes, with care. Both protocols use multicast, so IGMP snooping must be enabled on the shared switch. Assign different multicast address ranges (AES67 uses 239.69.x.x; Dante uses 239.255.x.x) to avoid collisions. For bridging between the two, the SUPERCAN AES67 Converter includes a Dante bridge mode.

What sample rate should I use for live sound?

48 kHz is the industry standard for live production and broadcast. Use 96 kHz only if every device in the chain — console, stage box, recorders — supports it. Mismatched sample rates produce audible distortion or silence.

How much latency does AES67 add compared to analog?

At 1ms packet time, AES67 adds approximately 2–5ms per network hop. For comparison, an analog snake adds 2.9ms per kilometer of copper cable. A 100m analog snake (0.29ms) has less inherent delay than AES67, but AES67 eliminates the cable run entirely in distributed systems.

Can I record multitrack via AES67 at the same time as live distribution?

Yes. AES67 streams are standard RTP/UDP, so any DAW with AES67 or RAVENNA support can record directly from the network while simultaneously distributing to the FOH console — no splitter or extra cabling required.