Dante Packet Errors vs Latency Errors: Diagnose the Right Network Fault

TL;DR — Dante packet errors and latency errors point to different boundaries. Packet errors indicate corrupted media between a switch and receiver and usually send you toward the physical link. Latency errors mean packets arrived too close to or after the receiver's playback deadline and send you toward buffer choice, path length, congestion, QoS, or topology. Capture counters and histograms under load, fix the cause, clear once for a controlled retest, and verify real audio.

Packet integrity and packet arrival time are separate checks

Dante Controller's Network Status view summarizes recent packet and latency behavior. A route can show one error type without the other, so diagnose the indicator that actually changed.

The Dante network health guide explains the full monitoring baseline. This guide owns the decision between physical corruption and late arrival.

Diagnose packet errors from the receiver backward

Packet errors in Network Status indicate damaged media on the final link toward the receiver. Open Device View > Status and record the receive error count, link state, speed, address, and utilization. Then inspect the connected switch port.

Work one boundary at a time:

1. preserve the current count and incident time;
2. reseat or replace the endpoint cable with a known-good cable;
3. inspect connectors, patch panels, adapters, optics, and switch port counters;
4. confirm expected speed and duplex negotiation;
5. move to a known-good port only in an authorized window;
6. clear counters once, reproduce full load, and confirm the count stays at zero.

Do not assume a small number is harmless. An old stable count may describe a past event; a count increasing during the dropout is strong evidence. Correlate both time and direction.

Diagnose latency errors with the histogram

Receiver latency is the interval available for a network packet to travel from transmitter to receiver before playout. Supported devices expose a histogram for each transmitter in Device View > Latency.

Read it in this order:

• Setting: the effective latency applied to the subscription;
• Peak: the slowest observed packet arrival;
• Average: the normal arrival region, not the worst case;
• Late measurements: observations containing one or more packets beyond the deadline;
• Distribution: green well inside the limit is healthy, amber approaches it, and red crosses it.

Multicast flows use at least 1 ms, and some transmitters negotiate a higher minimum than the receiver's configured default. Read the effective value shown for the subscription instead of assuming every route uses the same number.

Decide whether to repair the path or increase the buffer

Increasing receiver latency can be valid when the designed path has more switches, lower-speed links, or predictable variation than the existing setting allows. It is not a substitute for repairing corruption, congestion, incorrect QoS, or an unexpected topology.

Follow the Dante latency settings guide when a buffer change is justified. Changing latency re-establishes received flows and can interrupt audio, so use a maintenance window.

Prove the correction under representative load

1. Save routes, device settings, counters, histogram, and switch evidence.
2. Run the complete show routing, including multicast and backup traffic.
3. Reproduce the affected signal through its physical destination.
4. Apply one physical, network, QoS, topology, or latency correction.
5. Clear the relevant counters or histogram and record the new start time.
6. Repeat the same load and any approved failover scenario.
7. Confirm packet counts remain stable, latency stays inside the limit, and audio is clean.
8. Restore or retain the accepted state and document ownership.

If the fault cannot be reproduced, preserve the evidence and define a monitoring window rather than declaring success from a brief green screen.

Error-triage checklist

• Packet and latency indicators are treated separately.
• The affected receiver, transmitter, subscription, and time are named.
• Link speed, physical counters, and switch port are checked.
• Effective latency, peak, average, late measurements, and distribution are saved.
• Full production load and shared uplinks are included.
• Only one boundary changes per test.
• Counters are cleared only at the start of a recorded retest.
• Real audio, recovery, owner, and rollback are verified.

FAQ

What is the difference between Dante packet errors and latency errors?

Packet errors indicate corrupted media near the receiver's network link. Latency errors indicate packets arrived near or after the receiver's playout deadline. They require different first checks.

What causes packet errors in Dante Controller?

The usual boundary is the physical path between the switch and receiver: cable, connector, patch point, optics, port, or link negotiation. Confirm by watching whether the counter increases during the incident.

What causes Dante latency errors?

Causes include an undersized receiver buffer, too many or slow network hops, congestion, incorrect QoS, unexpected multicast traffic, topology changes, or constrained uplinks.

How do I read the Dante latency histogram?

Compare the distribution with the effective latency limit. Green measurements comfortably inside it are healthy, amber measurements approach it, and red measurements are late. Also record peak, average, and late-measurement count.

Should I increase Dante latency to stop audio dropouts?

Only after checking the physical path, capacity, QoS, topology, and device support. A larger buffer is appropriate for a valid longer or more variable path, but it should not hide corruption or congestion.

Put the diagnostic boundary in the Rider

Record the affected route, indicator type, counters, histogram, path, setting, test load, corrective action, acceptance result, owner, and rollback in Techrider.live. Invite the system and venue engineers to edit the same Rider, save the approved baseline, and inspect history when the path changes.