Most live sound and broadcast engineers work with both AES3 and AES67 without thinking much about the underlying standards — until the day they need to connect an older stagebox to a new IP audio network, and suddenly the difference matters a great deal.
This guide breaks down exactly what separates AES3 from AES67, where each standard belongs in a modern signal chain, and how to bridge them cleanly when your infrastructure mixes both.
What Is AES3 (AES/EBU) Digital Audio?
AES3 — formally AES/EBU, named after the Audio Engineering Society and the European Broadcasting Union — is a point-to-point digital audio standard published in 1985 and revised multiple times since. It carries two channels of PCM audio per cable at up to 24-bit resolution and sample rates up to 192 kHz.
Physical Layer
AES3 runs over a balanced, 110Ω XLR cable — the same connector used for analogue microphone and line signals, with slightly tighter impedance tolerances. Maximum cable run before signal degradation depends on sample rate: at 48 kHz you can typically run 100 m reliably; at 192 kHz that drops to around 10–15 m without a dedicated AES3 line driver.
Consumer variants of the standard use unbalanced coaxial cable at 75Ω (S/PDIF on phono connectors), but in professional audio the balanced XLR form is universal.
Channel Count and Routing
Each AES3 cable carries exactly two channels: an odd channel (left/A) and an even channel (right/B). To carry a 48-channel console’s output to a stagebox, you need 24 separate XLR pairs — which is why AES3 infrastructures quickly accumulate large cable runs and patch bays. Multicore snakes bundle 8, 16, or 32 pairs, but each pair still requires its own dedicated connection.
Routing changes require physical re-patching or dedicated AES3 router hardware. There is no software-defined routing in native AES3.
Where AES3 Fits Today
AES3 remains dominant in analogue-digital console I/O, broadcast studio wiring between desks and hardware outboard, recording studio patchbays where deterministic low-latency digital routing matters, and legacy tour rigs where the infrastructure investment in multicore is already sunk.
If you’re running AES3 over long XLR runs, an XLR audio isolation transformer eliminates ground-loop interference that can corrupt the signal frame — without introducing processing delay.
What Is AES67 Network Audio?
AES67 is an AIP (Audio over IP) interoperability standard published by the AES in 2013. Unlike AES3, it does not define a physical cable type — it defines how audio is packetised and transported over standard Gigabit Ethernet networks using RTP (Real-time Transport Protocol) and IEEE 1588 PTPv2 clock synchronisation.
The key breakthrough: AES67 is a convergence layer. It gives Dante, RAVENNA, Livewire, Q-LAN, and other proprietary AoIP ecosystems a common interoperability profile — so a Dante console can send audio to a Livewire radio broadcast system without hardware conversion, as long as both support AES67 mode.
How AES67 Audio Works
At a technical level, AES67 streams audio as multicast or unicast RTP packets over UDP/IP. Streams carry 1–8 channels per flow, at 16- or 24-bit depth and sample rates of 44.1, 48, or 96 kHz. The standard mandates a maximum end-to-end latency of 1 ms at default settings (1 ms packet time), though many implementations support down to 250 µs for low-latency applications.
Clock accuracy is maintained by IEEE 1588 PTPv2 (Precision Time Protocol v2), which synchronises all network nodes to a grandmaster clock with sub-microsecond precision. This replaces the word-clock infrastructure of traditional AES3 digital audio.
Channel Density and Routing
Where AES3 requires one XLR pair per two channels, a single Gigabit Ethernet port can carry thousands of AES67 channels simultaneously. Routing is software-defined: any source to any destination on the network without physical re-patching.
This makes AES67 compelling for large touring productions, broadcast facilities replacing analogue patch bays with IP routing matrices, installed sound systems where routing changes are managed from a network controller, and radio and TV production where Livewire, RAVENNA, and Dante sources all need to co-exist.
The SUPERCAN AES67 Converter bridges AES3 hardware directly into Dante, RAVENNA, and Livewire networks with 24-bit/96 kHz audio and PTPv2 clock synchronisation.
AES3 vs AES67: Side-by-Side Comparison
| Feature | AES3 (AES/EBU) | AES67 |
|---|---|---|
| Transport | Balanced XLR (110Ω) | Gigabit Ethernet (Cat5e/6/6A) |
| Channels per cable | 2 | Thousands (network-shared) |
| Max resolution | 24-bit / 192 kHz | 24-bit / 96 kHz (standard) |
| Latency | < 50 µs (cable only) | 1 ms default (250 µs low-lat) |
| Routing | Fixed / hardware patchbay | Software-defined, any-to-any |
| Clock | Embedded in bitstream | IEEE 1588 PTPv2 grandmaster |
| Cable runs | Up to ~100 m (at 48 kHz) | 100 m per switch hop (unlimited hops) |
| Interoperability | Universal (fixed standard) | Requires AES67 mode in device |
| Setup complexity | Low — plug and play | Moderate — network config needed |
| Infrastructure cost | High at scale (multicore) | Low at scale (Ethernet switches) |
The trade-off is clear: AES3 wins on simplicity and ultra-low latency for short-haul point-to-point connections. AES67 wins on channel density, flexibility, and long-distance routing at scale.
When You Need to Bridge AES3 and AES67
Most engineers today work in a hybrid world. Broadcast facilities have racks of AES3-wired hardware — ADCs, DACs, legacy consoles — that need to feed an IP backbone. Touring rigs use Dante desks but connect to venue infrastructure running AES3 stageboxes. Recording studios have AES3 patchbays but want the routing flexibility of a RAVENNA network.
The practical answer is a hardware bridge: a device that accepts AES3 signals on one side and presents them as AES67 streams on the other, with full clock conversion in both directions.
What to Look for in an AES67 Converter
Bidirectional conversion — some converters are AES3-input only. A true bridge operates in both directions: incoming AES67 streams can feed AES3 outputs, and incoming AES3 signals become AES67 multicast streams.
PTPv2 clock lock — the converter must derive its sample clock from the IEEE 1588 grandmaster on the network, not from a free-running internal oscillator. Any clock drift will cause the AES3 output to slip samples relative to the network.
Supported protocols — check whether the device speaks native Dante, RAVENNA, and Livewire AES67 interop mode, or only one of them. A converter that only passes raw AES67 RTP streams will not appear in a Dante Controller without Dante-native support.
Latency budget — for broadcast applications where AES3 outputs feed on-air monitors, total bridge latency (AES3 → AES67 → AES3 return) needs to stay within your acceptable lip-sync window.
The SUPERCAN AES67 Converter supports Dante, RAVENNA, and Livewire at 24-bit/96 kHz with PTPv2 clock lock and under 1 ms bridge latency — and it ships with XLR I/O and a standard RJ-45 Ethernet port, so no adapters are required.
AES67 Setup: Getting Your Bridge Online
Setting up an AES67 bridge for the first time takes around 20–30 minutes on a properly configured network. Here is the practical sequence.
- Prepare the network. AES67 requires a managed switch with IGMP snooping enabled (to control multicast traffic) and a PTPv2-capable grandmaster. Most Dante and RAVENNA devices include a grandmaster-capable clock, so you may already have one in the rig.
- Connect and power the converter. Connect your AES3 source to the XLR inputs of the bridge. Connect the Ethernet port to your managed switch. Most converters auto-negotiate Gigabit at link-up.
- Assign a static IP or use DHCP. For production use, a static IP is recommended so the device always appears at the same address in your routing controller.
- Configure AES67 mode in your ecosystem. In Dante Controller, enable AES67 mode on the relevant Dante device. In RAVENNA systems, set the bridge as an AES67 sender/receiver. Livewire uses a web interface to map sources.
- Verify clock lock. The converter’s status indicator should show PTPv2 lock within 5–10 seconds. If it does not, check that IGMP snooping is handling PTP multicast groups (224.0.1.129) correctly.
- Route and test. Route the AES67 stream to your destination in software, then verify the AES3 output with a reference signal. Listen for clicks or dropouts indicating sample-rate mismatch or clock instability.
If your AES3 outputs show ground-loop hum after bridging, an isolation transformer on the XLR feed resolves it without affecting the digital signal frame.
Frequently Asked Questions
What is the main difference between AES3 and AES67?
AES3 carries two channels of digital audio per XLR cable, point to point, with no network infrastructure required. AES67 carries audio over IP networks, supporting thousands of channels routed in software with PTPv2 clock synchronisation. AES3 has lower inherent latency; AES67 offers far greater flexibility at scale.
Can AES3 and AES67 work together in the same rig?
Yes. A hardware AES67 converter bridges AES3 hardware into an IP audio network and vice versa. This is the standard approach in hybrid rigs where legacy AES3-wired outboard hardware needs to connect to a Dante or RAVENNA backbone.
Is AES67 the same as Dante?
No. Dante is a proprietary AoIP protocol developed by Audinate. AES67 is an open interoperability standard. Dante devices can be placed in AES67 mode to send and receive standard AES67 streams, enabling interoperability with RAVENNA, Livewire, and other AES67-compliant devices.
What sample rates does AES67 support?
AES67 supports 44.1 kHz, 48 kHz, and 96 kHz at 16- or 24-bit depth. 192 kHz is not defined in the current standard. AES3 supports up to 192 kHz, making it preferable for very high sample rate applications.
How much latency does an AES67 bridge add?
A well-designed AES67 bridge adds 1–2 ms of latency: approximately 1 ms for AES67 packetisation at default settings, plus converter processing time. For a round-trip path (AES3 in, AES67 network, AES3 out), budget 2–4 ms depending on network depth.
