Dante Latency Settings: Build a Reliable Live Audio Budget

TL;DR — A Dante receiver's latency setting is a packet buffer, not a speed control. Set it long enough for packets to cross the real switch path and arrive despite normal timing variation. A shorter value does not make the network itself faster; if packets arrive after the deadline, audio can click or mute. Count switch hops, verify supported values and link speeds, start with a stable margin, test under realistic traffic and failures, and document settings per receiving device.

Device latency is one part of the end-to-end delay

Dante transports digital audio in packets. A receiving device holds incoming packets briefly so it can play them in the correct order and at the correct time. Its configured receive latency defines that network buffer window.

The listener experiences more than this one setting:

Do not describe a network as “0.25 ms total latency” merely because one receiver shows that value. The setting covers the Dante network delivery window at that receiver, not every conversion, processor, and acoustic delay in the system.

Choose stability before the smallest number

Use the lowest supported setting that remains reliable for the real topology, but do not begin by chasing the minimum. The correct value depends on device capability, number of switch hops, link speeds, network design, and traffic conditions.

A conservative workflow is:

1. draw the longest transmitter-to-receiver path;
2. count every switch the media crosses;
3. confirm link speed at every hop;
4. check which latency values the receiver supports;
5. select a value with margin for the planned path;
6. test while the complete show traffic is active;
7. reduce only when the production has a measured reason.

Touring systems often meet unknown or changing venue networks. A slightly larger stable buffer is usually a better handoff than a fragile minimum that worked only on an empty bench network.

Count the path to each receiver

Latency is configured at receiving devices, so two destinations can legitimately use different values. An amplifier one switch away and a recorder across several distribution switches do not share the same path.

Build a path table:

Count physical switches, not IP subnets or cable labels. An unmanaged switch hidden in a rack still adds a hop. A link negotiating at 100 Mbps can become the limiting boundary even when adjacent ports are gigabit.

Understand late packets before changing the setting

A late-packet warning means media arrived after the receiver's current deadline. Increasing latency can provide more tolerance, but it should not replace diagnosis.

Common causes include:

• the setting is too short for the switch path;
• a link negotiated at an unexpected speed;
• a switch is overloaded or incorrectly configured;
• multicast traffic reaches links that do not need it;
• a cable, connector, optic, or adapter is producing errors;
• the topology changed without updating the latency plan;
• energy-saving or other switch behavior interferes with time-sensitive traffic.

Inspect device and switch counters, event history, link speed, clock status, and bandwidth. The Dante unicast versus multicast guide explains how unnecessary multicast can load constrained links. Fix the path when it is faulty; add buffer only when the path is valid but needs a larger delivery window.

Separate latency from clock and redundancy

Dante clock synchronization tells devices when samples belong in time. Receive latency allows packets to arrive before playback. A device can show a valid clock while media packets still arrive late. Check both states.

Redundant primary and secondary networks should each support the configured latency. The surviving path must remain within budget after a cable, switch, or power failure. The Dante redundant versus switched guide covers the required separation and failure-domain test.

Also separate transport latency from loudspeaker alignment. Output delay may intentionally align a fill or delay speaker to an acoustic reference. The channel delay versus output delay guide explains that processing decision. Do not lower the Dante buffer to compensate for an acoustic timing requirement.

Test the full network, not an idle patch

1. Save the known state

Record device names, firmware context, sample rate, clock leader, subscriptions, flow types, receiver latency settings, link speeds, topology, and switch configuration.

2. Verify normal audio

Run every required channel to its real destination. Confirm subscription, clock, packet, error, and latency indicators, then listen at the destination rather than relying on one green icon.

3. Load the network realistically

Activate recording, broadcast, amplifier, control, and other show routes. Measure bandwidth on core and edge links. An empty network cannot prove the show state.

4. Exercise the longest paths

Test receivers behind the greatest number of switches and any 100 Mbps or shared uplinks. Watch for late packets over a meaningful period while programme audio continues.

5. Remove real components

Where authorized, disconnect one redundant link or power one switch path down. Confirm the surviving path maintains clock, audio, and the latency budget. Restore the baseline before the next test.

6. Change one receiver at a time

If a different setting is justified, change only the affected receiver, clear or timestamp counters, repeat the full test, and save the accepted configuration. Do not globally increase every value to hide one bad link.

Document the latency budget in the Rider

The handoff should identify topology, longest paths, link speeds, receiver settings, expected traffic, warnings to inspect, test duration, failure test, owner, and approved baseline. “Low-latency Dante” is not measurable.

In Techrider.live, keep device and network notes aligned with the stage plot and signal handoffs, invite the system and recording engineers to edit the same Rider, save the accepted values, inspect history after a topology change, and export a dated PDF for the venue.

Dante latency checklist

• Every receiver's supported latency values are confirmed.
• Longest paths and all switch hops are mapped.
• Negotiated link speed is checked at every critical boundary.
• Show traffic, multicast, and constrained links are included in the test.
• Clock status and late-packet history are checked separately.
• Redundant-path failure remains within the accepted budget.
• Each setting, test result, owner, and baseline is documented.

FAQ

What latency should I set for Dante?

Choose a receiver-supported value that safely covers the actual switch path and traffic. Start with a stable margin, test the complete show network, and use a shorter value only when measurements justify it.

What causes late packets in Dante?

Packets can arrive late because the buffer is too short, the path has too many hops, a link is slow or faulty, traffic is excessive, or switch configuration is unsuitable. Diagnose counters and topology before changing settings.

Can Dante devices use different latency settings?

Yes. Latency is a receiver setting, and destinations with different paths or device capabilities can use different supported values. Record each one rather than assuming a single network-wide number.

Does a network switch add Dante latency?

Every switch must receive and forward packets, so the path and its queueing contribute to delivery time. Count all switches and verify link speeds when selecting and testing receiver latency.

How do you test Dante network latency?

Run all show routes, inspect clock and late-packet indicators, measure critical links, test the longest receiver paths, exercise authorized failures, listen at real destinations, and repeat after each controlled change.

Make the network budget repeatable

Create one Rider that names the path, switch hops, link speeds, receiver setting, traffic state, test, owner, and fallback for every critical Dante destination.