Dante Clock Sync Troubleshooting: Read Warnings, Unlocks, and Offset

TL;DR — Troubleshoot Dante clock sync from the event timeline, not the current green indicator alone. Capture the leader, follower state, warning or unlock time, mute state, offset history, link condition, traffic load, and external reference before changing settings. A warning means instability risk; an unlock means the device lost synchronization and may mute. Fix the earliest failing boundary, then verify stable offset and real audio under representative load.

A clock warning and an unlock are different events

Dante Controller monitors whether devices follow the elected network clock. Passive monitoring records lost and regained sync. Active monitoring, where supported and enabled, can also warn when a follower is becoming unstable before it unlocks.

A green state after recovery does not explain why the clock failed. Save the event log and correlate it with the reported dropout before clearing history or rebooting equipment.

Read the Clock Status Monitor in order

1. Identify the actual leader and clock domain

Open Clock Status and record the current leader, follower roles, sync state, sample rate, and any pull-up/down domain. Confirm that the affected transmitter and receiver belong to a compatible clock domain. The Dante clock leader guide covers election and Preferred Leader design; this guide focuses on diagnosing instability after the design exists.

2. Build the event timeline

Filter Events for warnings and errors, but save the complete log because saved logs include the full list. Note the first warning, unlock, mute, relock, and unmute. Compare those times with cable work, switch changes, route changes, load peaks, or external-clock events.

3. Inspect follower offset history

Clock offset is how far a follower must adjust its frequency to track the leader. A narrow, steady distribution is healthier than a broad or rapidly moving one. Amber or red measurements can mean the clock is close to its supported pull range. Offset is diagnostic evidence, not a universal pass/fail number; compare the device with its own baseline and neighboring followers.

4. Follow the common path

If many followers warn together, inspect the leader, its external reference, and shared switching path. If one follower is unstable, inspect that endpoint, cable, port, negotiated speed, errors, and local switch path. Keep primary and secondary networks separate and evaluate them independently.

5. Verify the external reference

When the leader derives timing from word clock or another host reference, confirm that source is present, nominal, and owned by one documented system. An inaccurate or changing external reference can force followers toward the edge of their pull range. Do not select a new Preferred Leader merely to hide the symptom.

Match the pattern to the boundary

Use the Dante network health guide for the broader utilization, error, and switch-path workflow. Avoid changing latency to solve a clock problem; receiver latency buffers media arrival, not PTP stability.

Run a controlled recovery test

1. Save the current routes, leader, sync state, event log, and offset baseline.
2. Run every required route under representative production load.
3. Confirm the warning or unlock can be correlated with a specific boundary.
4. Change one item: cable, port, EEE policy, load, external source, or clock configuration.
5. Observe leader election, follower offset, warnings, mute state, and real destinations.
6. Restore the approved topology and repeat long enough to cover the original failure window.
7. Save the clean event history and name the recovery owner.

Do not clear counters before capture. Clear them only when starting a deliberate comparison window, and record the exact time.

Clock-sync acceptance checklist

• The actual leader and clock domain are recorded.
• Warning, unlock, mute, relock, and recovery times are preserved.
• Offset history is compared with a known-good baseline.
• Link speed, errors, utilization, EEE, and shared paths are checked.
• Any external reference is verified at its source and host device.
• Primary and secondary networks are tested independently.
• Real audio remains correct after the controlled fix and restore.
• The final state, owner, escalation, and rollback are documented.

FAQ

Why does a Dante device lose clock sync?

Common causes include overloaded or unsuitable switching, a failing link, problematic EEE, an inaccurate external reference, incompatible clock domains, or loss of the leader path. Use time-correlated events and offset history to isolate the boundary.

What does Clock Sync Warning mean in Dante Controller?

It means active monitoring has identified significant clock instability and the device is at risk of losing sync. Preserve the event time and inspect offset, traffic, links, and clock sources before it becomes an unlock.

What happens when a Dante device clock unlocks?

The device has lost synchronization with the leader. Dante may automatically mute it until synchronization returns, so record both the clock and audio-mute events and verify the physical destinations after recovery.

How do I read Dante clock offset history?

Look for a stable, narrow distribution rather than a broad or rapidly changing range. Amber or red measurements may indicate limited pull-range margin. Compare with the device baseline and other followers on the same path.

How do I fix Dante clock sync problems?

Capture the event sequence, identify whether one or many followers are affected, inspect the relevant endpoint or shared path, verify the leader and external source, change one boundary, then retest offset and real audio under load.

Make the clock incident reproducible

Record the leader, domain, follower, event times, offset pattern, network path, external source, corrective change, acceptance result, owner, and rollback in Techrider.live. Invite the system and venue engineers to edit the same Rider, save the accepted state, and inspect history after future changes.