1
Dante, MADI, AES50: What Runs Where
Three protocols dominate live audio networking. Dante (Audinate) runs over standard Ethernet, is in nearly every modern brand, and is what touring techs actually fight with at 5 PM. MADI is the older 64-channel point-to-point standard, solid, simple, no IP layer to break. AES50 is Behringer/Midas-only, used on the X32 family, carries 48 channels over a single CAT-5.
Know which world you are in: a Dante problem is a network problem (switches, IP addresses, multicast). A MADI problem is a cable or clock problem. An AES50 problem is usually a stage-box link cable.
In practice: CL5 + DX32 stage box: Dante. M32 + S32 stage box: AES50. SSL Live + Net I/O Stage Box: a custom protocol, but the same idea applies, know what runs between desk and rack.
Dante = standard Ethernet, everywhere. MADI = point-to-point coax/fiber. AES50 = Behringer/Midas, CAT-5.
2
Clock Master: Why Only One Device Wins
Networked digital audio needs every device sampling at exactly the same instant. One device, the clock master, broadcasts the timing reference via PTP (Precision Time Protocol on Dante, similar mechanisms elsewhere) and every other device locks to it.
The single most common mistake on a new rig is leaving "Preferred Master" enabled on multiple devices. Two stable clocks fighting for master is worse than one shaky one, the network re-elects mid-show and you get audible clicks.
In practice: New touring rig: pick the FOH console as Preferred Master, every other Dante device set to None or Slave. Verify in Dante Controller before doors.
One Preferred Master per network. Two clocks fighting is worse than one slow one.
3
Dante Latency: Why 0.25 ms Is a Lie
The Dante latency setting in Dante Controller only covers the network hop, typically 0.25 to 2 ms. Total signal-path latency is the sum of everything from microphone diaphragm to ear: preamp ADC, console DSP, plugins, network transport, DAC, IEM transmission. On a typical Yamaha CL/QL + Rio + Shure PSM1000 path it adds up to 4-8 ms.
Vocalists feel latency past about 5 ms. They cannot tell you "5.3 ms", they say "my voice sounds late" or "I keep going sharp". When that happens, audit the whole budget, not just the Dante setting.
In practice: Singer says IEM feels delayed: drop Dante from 1 ms to 0.25 ms, bypass any plugins on the vocal IEM aux, and check the IEM RF latency spec.
Dante latency ≠ total latency. Singers feel >5 ms: audit the whole path.
4
Primary/Secondary: Dante Redundancy Done Right
Dante Redundancy mode runs two physically separate networks, Primary and Secondary, in parallel. Every device with two Dante ports plugs into both. If one network fails (cut cable, dead switch, power glitch), audio continues uninterrupted on the other. The receiver picks whichever stream arrives first.
The rule that breaks it: the two networks must never share a switch, a cable, or even a power circuit. Bridge them and you no longer have redundancy, you have one network with a complicated failure mode.
In practice: Tour rig: Switch A on stage UPS, Switch B on FOH UPS, two fiber trunks routed on opposite sides of the room. Every Rio, console, and IEM rack patched to both.
Redundancy = two separate networks on separate power. Bridging them defeats it.
5
Dante Switches: What "Managed" Means and Why
A Dante network is fragile if the switch is wrong. Real requirements: IGMP snooping (multicast filtering: without it, audio floods every port), QoS/DSCP prioritization (so audio gets priority over file copies), full gigabit (no auto-negotiation down to 100 Mbps), and Energy Efficient Ethernet (EEE / Green Ethernet) disabled (EEE introduces clock jitter).
Audinate publishes a certified switch list. Working off-list works for a few devices, but past a dozen the cheap switches start dropping packets in ways that are very hard to diagnose.
In practice: A 24-channel Dante rig running fine in soundcheck then dropping IEMs mid-show: the switch is probably an unmanaged consumer model, multicast flooding under load.
Managed switch + IGMP snooping + QoS + EEE off. Don't skimp here.
6
Dante Controller Just Went Red. Now What?
Dante errors look alarming but they are diagnosable. The trick is reading the actual icon and treating it as a clue, not a generic "broken" indicator.
Clock master errors mean fight over Preferred Master or master went offline. Subscription errors with red text usually mean a device name changed. "!" on a whole device means it fell off the network or has an IP conflict. "x" on a subscription means the source disappeared. Each fix is different, reboot-and-pray loses the ten minutes you have before doors.
In practice: Subscription label turned red but stage box is healthy: source device was renamed. Resubscribe by current name, or rename the device back.
Read the icon. Clock, subscription, device, IP: each has a different fix.
7
The Cable Is the Network: Connectors, Distance and What Actually Fails
Networked audio is discussed as a protocol problem and fails as a physical one. The overwhelming majority of intermittent faults are connectors, strain and distance.
The limits worth knowing: copper is good for about 100 metres including the patch leads at each end, and past that you get exactly the intermittent behaviour people blame on software. Beyond that distance the answer is fibre.
The hardware that matters: locking, strain-relieved connectors rather than bare RJ45, because the plastic tab is the weakest link in the whole signal path and it snaps. A service loop at each end so a pulled cable moves rather than loading the connector. Factory-terminated cable rather than field-terminated for anything that matters, and shielded cable where there is heavy mains or dimming nearby.
And the diagnostic habit: when a link is intermittent, work the physical layer before the configuration. The configuration worked at soundcheck; the cable has had a show happen to it since.
In practice: A stage box dropping for a second at a time through the first set: check seating and strain, walk the run to see what has been put on it, and count the true length including patch leads.
Copper runs about 100 metres including patch leads, connectors need locking and a service loop, and an intermittent link is a physical-layer fault until proven otherwise.
8
Sharing a Network With Lighting and Video
Sharing one network across audio, lighting and video is normal practice on a well-designed installation and a reliable way to lose a show on an improvised one. The difference is entirely in the design.
What has to be true: segregation, with VLANs or separate physical networks; managed switches with IGMP snooping configured rather than whatever hardware was nearest; and a named person who owns the network and whom people ask before plugging anything in.
The specific mechanism that hurts audio is multicast flooding. Networked audio is multicast, and a managed switch only forwards those streams to ports that requested them. An unmanaged switch forwards everything to everywhere, so the moment one appears the audio streams are competing with video traffic on every port. Audio is the department with the tight latency and clocking requirements, so audio is the department that glitches.
When the ownership and the design are not there, keep audio on its own physical network. A run of cable is cheaper than the show.
In practice: Video adds an unmanaged switch and audio starts glitching: that switch is flooding multicast. Remove it, then argue for a named network owner rather than for being right.
Shared networks need VLANs, managed switches and an owner. Without all three, give audio its own physical network.
9
Clocking a Hybrid Rig: Network, Word Clock and Legacy Gear
Adding networked audio to a rig that still has AES or word-clock gear does not create two independent clock domains. It creates one clock problem with a boundary in the middle of it.
There is still exactly one clock authority for the whole rig, and the real work is defining the path from it into every domain. The network elects its master; the legacy side needs that same reference distributed to it, whether as word clock or embedded in an AES stream. Anything left free-running, or following a reference that is not the system reference, is the intermittent tick you will spend the show chasing.
The symptom is characteristic and worth recognising: ticking or brief dropouts on the specific channels that cross the boundary, while every device reports itself healthy. Audio sampled against one reference and consumed against another slips slowly, which is why it is intermittent.
The prevention is trivial and almost never done. Draw the clock tree as part of the system design, write it into the show file, and verify it before doors.
In practice: Ticking only on channels through one AES outboard unit while the network reports healthy: that device is clocking from the wrong source. Give it the system reference explicitly.
One clock authority, a defined path into every domain, and a written clock tree. Ticking on just the channels that cross a boundary is a clock fault, not a cable.
These lessons are the teach side of knowledge cards from the Live Sound deck. In the daily plan each one is followed by a quiz, spaced over weeks, so it stays known rather than read once.