Dante Clock Leader and Preferred Leader: Configure Sync Safely

TL;DR — Dante devices use Precision Time Protocol to elect one clock leader while the other devices follow it. Leave election automatic unless the production has a measured reason to prefer a specific reliable device. Preferred Leader changes election priority; Enable Sync to External makes a Dante interface follow its host's external reference. Avoid competing settings, verify the actual leader and clock domain, test loss and recovery on the real network, and document the accepted state.

The clock leader gives every device one timing reference

Digital audio devices must agree when each sample occurs. Dante distributes that timing through Precision Time Protocol (PTP). One eligible device becomes the clock leader for a clock domain, and the other devices synchronize as followers.

Clock leadership does not route audio and does not choose subscriptions. A device can be visible and subscribed yet mute when its clock is unlocked or incompatible. Treat routing, clock, sample rate, and network health as separate checks.

Let automatic election work unless the design needs control

Dante normally elects a leader automatically from eligible devices. For many small and medium systems, that is the safest starting point: confirm the elected device is stable, then leave the election alone.

Consider Preferred Leader only when the production needs a predictable candidate, such as a central device that remains powered for the entire event or a device tied to an approved external reference. The choice should improve operational clarity or system stability, not merely make the controller screen look tidy.

Before enabling it, ask:

• Will this device remain present and powered during load-in, show, and strike?
• Is its primary and, where applicable, secondary network path reliable?
• Does it have a stable internal clock or a verified external reference?
• What device should lead if it disappears?
• Can the crew identify the election result and recover without guessing?

Avoid selecting Preferred Leader on several devices without a documented election plan. The network will still choose one winner, but the outcome may depend on tie-breaking rules rather than the production's intended priority.

Keep Preferred Leader and external sync distinct

Preferred Leader affects which Dante device wins the network election. Enable Sync to External affects where that Dante device derives its timing. They are related but not interchangeable.

A device set to sync externally should receive a valid word-clock, AES3, or other supported host reference. If another device is forced to become Preferred Leader while the externally synchronized device follows a different reference, the design can create incompatible timing and eventually mute audio.

Use this sequence:

1. identify whether the system needs an external reference at all;
2. name the single authoritative source for the clock domain;
3. confirm the host device is configured to provide that source to its Dante interface;
4. set Preferred Leader only where the approved design requires it;
5. verify the actual elected leader, clock source, sync state, and mute state;
6. save the accepted configuration and recovery path.

The word clock versus timecode guide explains why audio sample timing and production timecode solve different problems.

Diagnose clock instability before changing priorities

A clock warning is evidence about timing stability, not an instruction to click Preferred Leader. Common boundaries to inspect include:

• overloaded or incorrectly configured network links;
• Energy Efficient Ethernet behavior on unsuitable switches;
• an unexpected 100 Mbps link where gigabit is required;
• an unstable or incorrectly connected external word clock;
• incompatible clock domains or sample-rate pull-up/down settings;
• a leader device or network path that powers down during the show;
• redundant networks that do not preserve the intended timing path.

Check the clock-status event log, current leader, source, follower lock, frequency-offset history where supported, mute state, link speed, errors, and recent topology changes. Do not hide repeated unlocks by forcing a different leader before finding the failing boundary.

Test leadership, loss, and recovery

1. Save the baseline

Record device names, firmware context, sample rates, clock domains, current leader, Preferred Leader settings, external-sync settings, network paths, and subscriptions.

2. Verify the normal state

Confirm the intended leader is actually elected. Check every required follower is locked and unmuted, then listen at the real destinations.

3. Remove the leader deliberately

During an authorized test window, disconnect or power down the leader. Observe election time, the new leader, clock warnings, audio continuity, and any mute interval. Restore the device and confirm the network returns to the accepted state.

4. Test the external source

If external sync is used, remove or invalidate only that source under controlled conditions. Record how the host and Dante interface report the fault, whether audio mutes, and the exact recovery steps.

5. Test redundant paths

For supported redundant devices, test primary and secondary failures independently. The Dante redundant versus switched guide explains the physical separation required for a real backup path.

6. Recheck after every format change

Changing sample rate, pull-up/down, device mode, firmware, or network topology can alter eligibility or domain membership. Verify the election again rather than assuming the previous leader remains valid.

Put clock ownership in the Rider

A useful handoff names the intended and fallback leaders, device clock sources, Preferred Leader state, external-reference source, clock domain, sample rate, primary and secondary paths, monitoring method, authorized failure test, expected recovery, and responsible technician.

In Techrider.live, align device names with the network and I/O lists, invite the system and recording engineers to edit the same Rider, save the accepted clock plan, inspect history after a change, and export a dated PDF for load-in.

Dante clock checklist

• The actual leader and every follower's lock state are verified.
• Preferred Leader is used only for a documented reason.
• External sync has one valid, named reference per clock domain.
• Sample rate and pull-up/down settings are compatible.
• Clock warnings, mute state, link speed, and event history are checked.
• Leader loss, external-source loss, and recovery are rehearsed.
• Redundant paths preserve a valid timing reference.

FAQ

What is the clock leader in Dante?

The clock leader is the elected device that supplies PTP timing to the other devices in its Dante clock domain. Followers use that reference to keep digital audio samples aligned.

Should I set a preferred leader in Dante?

Only when the system has a clear reason to favor a specific reliable device. Automatic election is appropriate for many systems. If Preferred Leader is used, document the fallback and test removal of the preferred device.

What does Enable Sync to External do in Dante?

It tells the Dante interface to derive timing from an external reference supplied by its host equipment. That source must be valid, correctly connected, and compatible with the rest of the clock domain.

Why does a Dante device lose clock sync?

Possible causes include an unstable external reference, overloaded or unsuitable switching, incorrect link speed, incompatible clock domains, format changes, or loss of the timing path. Inspect status and event history before changing election settings.

How do you test Dante clock failover?

Save the baseline, verify every follower, remove the current leader during an authorized window, observe the new election and real audio destinations, restore the device, and confirm the intended state returns.

Make timing ownership testable

Create one Rider that names the leader, fallback, clock source, domain, network paths, monitoring, failure test, and recovery before the system reaches the venue.