## Dante vs Ravenna - audio networking in practice

Two worlds, one cable

Audio networking is a topic that sounds like “something from IT” to most sound engineers. And in a sense it is - we send audio over the same cables and switches as internet traffic. But the requirements are radically different: zero tolerance for latency, deterministic packet delivery, synchronization accurate to microseconds.

I work with two main protocols: Dante at Flightcore Studios and Ravenna (via Merging Horus converters) at the National Philharmonic. Both do the same thing - transport multichannel digital audio over Ethernet - but they approach it differently.

Dante - ecosystem and pragmatism

Dante, developed by Audinate, is the de facto standard in commercial recording studios and live installations. Its strength lies not in technical superiority over the competition, but in its ecosystem.

What works well

• Dante Controller - centralized audio routing management from a single application. You can see every device on the network and reroute any channel in seconds.
• Compatibility - Shure microphones, Yamaha consoles, Allen & Heath stageboxes, Focusrite interfaces - everything speaks the same protocol. At Flightcore we have gear from several manufacturers and it all connects without issues.
• Redundancy - two ports (primary/secondary) on every device. If a switch or cable fails on the main path, audio switches to the backup without interruption.

Limitations

• Proprietary protocol - Dante is Audinate’s proprietary solution. Licenses cost money, and interoperability with other protocols (AES67, Ravenna) requires a dedicated gateway or a device that supports both standards.
• Dependency on Dante Controller - without this application, configuration is practically impossible. It doesn’t run natively on Linux, which complicates management in pure Linux environments.
• Multicast and QoS - Dante requires properly configured IGMP snooping on switches. Without it, multicast traffic floods the network, causing jitter and clicks. This isn’t a flaw of the protocol itself, but in practice many technicians forget about network configuration and then look for the problem in the audio gear.

# Check IGMP snooping on a switch (Linux bridge example)
bridge -d link show | grep mcast
cat /sys/devices/virtual/net/br0/bridge/multicast_snooping

Ravenna - open standard and precision

Ravenna, developed by ALC NetworX, is an open protocol based on the AES67 and SMPTE ST 2110 standards. At the National Philharmonic I work with Merging Horus converters, which use Ravenna as their native transport.

What sets Ravenna apart

• Openness - built on open standards (AES67, PTP/IEEE 1588). No vendor lock-in, and interoperability with other AES67 systems is built in.
• Synchronization precision - PTP (Precision Time Protocol) in Ravenna offers clock synchronization accurate to below a microsecond. For the Merging Horus, which operates at resolutions up to 384 kHz DXD and DSD256, this is critical.
• Configuration flexibility - Merging ANEMAN (Audio Network Manager) allows more granular audio flow management than Dante Controller. You can define unicast and multicast streams independently and control each flow’s parameters separately.

Where Ravenna falls short

• Ecosystem - a significantly smaller selection of devices than Dante. The studio segment is dominated by Merging and a few broadcast manufacturers. In live sound it’s virtually non-existent.
• Learning curve - configuring Ravenna requires a deeper understanding of networking than Dante. You have to manually manage PTP domains, streams, and multicast addressing. Dante hides this complexity behind a simple drag-and-drop interface.
• Technical support - smaller community, fewer training materials, smaller forums for finding solutions.

MADI and AES/EBU - older protocols still in play

In both environments - Flightcore and the Philharmonic - we still use MADI (Multichannel Audio Digital Interface) and AES/EBU as point-to-point transports. MADI over BNC or fiber delivers 64 channels on a single cable, which works perfectly at the Philharmonic for connections between stage and control room.

AES/EBU is a classic - two channels on a cable pair, but with precise clocking and high noise immunity. At Flightcore Studios we use AES/EBU to connect monitoring speakers, where we need deterministic, minimal latency without network overhead.

# Typical interface configuration at Flightcore studio
studio_a:
  dante: 64ch  # main transport
  madi: 64ch   # backup / overflow
  aes_ebu: 2ch # monitoring
  wordclock: BNC # external sync

What I choose and why

There’s no single answer. Context decides:

• Commercial studio (Flightcore) → Dante. Ecosystem, gear compatibility, ease of use for visiting technicians.
• Concert institution (Philharmonic) → Ravenna/AES67 + MADI. Open standards, synchronization precision, long-term independence from a single vendor.
• Point-to-point, monitoring → AES/EBU or MADI. Minimal overhead, deterministic latency.

The key lesson: a protocol is a tool, not a religion. At Flightcore, Dante has been running flawlessly since opening in 2023. At the Philharmonic, Ravenna with the Merging Horus delivers precision that Dante can’t match for DXD recordings. Both solutions require solid network infrastructure - and that brings us back to Cat6A, managed switches, and properly configured QoS.

You can change the protocol. Badly run cables stay for years.