A Dante network that stays up

Audinate won't recommend a brand or model, but their checklist is short: gigabit ports, at least between switches; DiffServ (DSCP) QoS with strict priority and four queues; a way to turn Energy Efficient Ethernet off; and IGMP snooping with a querier if the network is going to need it. A managed switch is preferred because it lets you see port speeds, error counters and bandwidth, which is most of fault-finding.

Energy Efficient Ethernet off, on every port. EEE (802.3az, sold as "Green Ethernet") naps the link between packets, and Audinate's verdict on it is a one-word "no": it causes poor sync and the occasional dropout. On an unmanaged switch you can't turn it off, so don't use an unmanaged switch that has it. The same goes for unmanaged switches with IGMP snooping baked in.

Filter Unregistered Multicast off. Some switches ship with it on. It drops PTP, mDNS and Dante discovery, and the symptom is devices that won't show up in Dante Controller.

QoS on. Audinate only require it where there are 100 Mbps links or the network is shared, and recommend it everywhere. I'd turn it on everywhere: it costs nothing on a quiet network and saves the day on a busy one. From 32 channels up you need gigabit; below that a 100 Mbps switch can work, with QoS on.

bits/s = (overhead + channels × samples × bytes) × 8 × rate ÷ samples

Dante packs channels into flows. A unicast flow goes to one receiver and has room for four channels; a multicast flow goes to anyone who asks. Each packet carries a run of samples for every channel in the flow, behind a 9-byte Dante header, UDP, IPv4 and Ethernet. That's 55 bytes of overhead a switch counts per packet, and 75 once the preamble and inter-frame gap the link also carries are added.

Audinate quote "about 6 Mbps per typical unicast audio flow" and, for multicast, "about 1.5 Mbps per channel". Those are one figure said twice: four 24-bit channels at 48 kHz, sixteen samples a packet, counted at the frame. My capture has that flow in it, and the model below gets its frame size right to the byte.

Audinate's rule of thumb is that no link should run above 70 % of its speed, unicast and multicast together, because above that the clock starts to suffer. The limit applies to each direction separately, since the links are full duplex. With the typical flow at 6.41 Mbps on the wire, that gives the table.

A 64-channel stagebox sending to a desk is 16 unicast flows, or 102.5 Mbps. That doesn't fit a 100 Mbps link even at 100 %, before anything else happens on it. Audinate draw the gigabit line at 32 channels, a little inside the 40 the arithmetic allows, which is the right side to err on.

Dante routes unicast by default, one flow per transmitter and receiver pair. Every device has a fixed number of flows each way: two to four on Ultimo and AVIO-class hardware, many more on Brooklyn and Broadway-class. Device View's Transmit and Receive tabs show the figure for each box. Run out on the transmit side and Dante Controller says "No more flows (TX)".

Multicast sends one copy to everyone who wants it. The user guide's rule of thumb is to use it once more than two receivers want the same channels, and to assume the flow floods every link in the network. Unlike unicast it uses bandwidth even with nobody listening, and receivers will move across to a multicast flow on their own if one appears carrying channels they already take as unicast.

So 32 channels to 6 amp racks is 48 unicast flows and 308 Mbps leaving the transmitter, more transmit flows than plenty of devices own. As 4 multicast flows of 8 channels it's 44 Mbps, but that 44 Mbps now reaches every port on the network, including the 100 Mbps port on a two-channel wall plate in the bar.

That flooding is what IGMP snooping prunes: the switch listens to who has joined which group and sends the multicast only there. Audinate's position is that you don't need it on a small Dante-only network with little or no multicast audio, and that it's needed when:

• Dante or AES67 multicast flows are in use.
• The network carries other multicast, such as IP video.
• Control systems share the network with Dante.
• There are 100 Mbps links, or a Wi-Fi access point on the same network.
• Total multicast passes about 80 Mbps. That's all of it, not only the Dante multicast audio figure at the foot of Dante Controller.

Snooping needs a querier: exactly one per VLAN, asking every ~30 s, with a timeout of ~125 s. Turn snooping on without one and the switch learns each group when a receiver joins, nobody asks again, and with the RFC 2236 defaults the entry expires 260 s later. Multicast audio that stops about four minutes into soundcheck is the classic symptom. Audinate don't support IGMP proxies or PIM, and say Fast Leave does no harm.

Dante syncs with PTP version 1 (IEEE 1588-2002) by default. One leader per subnet multicasts Sync and Follow-up messages, about four a second (my bench's leader managed 3.87), and every follower sends delay requests back. No PTP-aware switches needed. The election prefers a device with a word clock or AES3 input, then one on gigabit over one on 100 Mbps, then the lowest MAC address.

Left alone that usually picks something sensible, and occasionally picks the stagebox that's about to be unplugged for the changeover. A leader change doesn't drop audio by itself: followers free-run for the few seconds the election takes. But if the old or the new leader is syncing to an external clock, everything mutes until it has resynced. So choose:

• Preferred Leader on one device that's on for the whole show, ideally the desk or a processor at FOH. It always wins. Set it on two and the lower MAC address wins, which probably isn't what you meant.
• Enable Sync To External only on a device that's actually fed word clock, and make that device the Preferred Leader as well. A device syncing to external while another device is Preferred Leader loses sync and is eventually muted.
• Mind the leader's capacity. Audinate rate a leader at 250 followers for Brooklyn, Broadway, HC and PCIe-class hardware, and 40 for UltimoX and AVIO-class. Past that, devices mute rather than play out of sync.

From 3 to 10 hops Audinate's current FAQ asks for twice the latency the manufacturers' table does. Audinate's own Dante Controller user guide sides with the manufacturers: the 1 ms default is "sufficient for a very large network, consisting of a Gigabit network core (with up to 10 hops between edge switches) and 100 megabit links to Dante devices".

I'd start from the lower table, then watch the Latency tab in Device View while the show is running and raise anything that goes amber. The FAQ also notes that a badly configured switch adds latency of its own, which may be why its figures are cautious. Changing a device's latency re-establishes its flows, so do it before doors.

A redundant Dante device sends the same audio out of its primary and secondary ports, onto two physically separate networks. Pull a cable or lose a switch on one side and the audio carries on over the other. That only works while the two networks stay apart, and the user guide's list of ways to break it is mostly variations on joining them:

• a secondary cable plugged into a primary switch,
• primary and secondary switches linked to each other, or one switch used for both,
• one DHCP server, or two serving the same range, on both networks.

Secondary ports can't talk to primary ones in any case. Devices without redundancy go on the primary only. Both ports on a redundant device must run at the same speed, or redundancy stops working for that device, and it won't come back after a replug until they match again.

Switched mode is the other thing a secondary port can be. Plenty of devices ship with the secondary port as a plain switch port, set in the Network Config tab's Switch Configuration, so you can daisy-chain the next box off it. Audinate's answer to "can Dante devices be daisy chained?" is "in most cases no": every box in the chain is another hop, and one dead box takes out everything downstream. Plug a switched-mode port into the secondary network and you've joined the two networks through the device.

Each network elects its own leader, normally the same device on both. With no DHCP on the secondary, its devices self-assign in 172.31.0.0/16, and a laptop's second interface needs a static address in that range to see them. Under Dante Domain Manager, redundancy only works within a subnet.

Out of the box a Dante device asks for DHCP, and if nobody answers it gives itself a link-local address: 169.254.0.0/16 on the primary, 172.31.0.0/16 on the secondary. On a standalone show network that's all you need. Set the laptop running Dante Controller to obtain its address automatically and it lands in the same range.

Devices keep looking for DHCP after they've self-assigned. That's handy on an installed network and a trap on a temporary one: the first time a router with DHCP turns up on the show network, every device takes a lease and moves.

• Pick one scheme. Audinate warn that mixing DHCP and link-local on one network causes trouble, and often everything, laptop included, has to be on one or the other.
• Static addresses work on most devices but need a reboot, and must sit in the same subnet as everything else. Audinate's view is that you shouldn't normally need them.
• Never let a DHCP server hand out 172.31.x.x on the primary network.
• Dante video devices need routable addresses, from DHCP or static, and mustn't rely on link-local.