Dante Unicast Delay Requests: Reduce PTP Multicast Safely

6 min read · Updated October 14, 2026 · AV network engineers, system technicians, FOH and monitor engineers, broadcast operators, venue technicians, integrators, and production managers

Understand Dante Unicast Delay Requests, confirm leader compatibility, enable followers safely, and verify clock stability under representative network load.

TL;DR — Dante clock followers normally use delay-request messages to measure network travel time to the clock leader. On supported devices, Unicast Delay Requests send those messages directly to the leader instead of using multicast, which can reduce multicast control traffic on large networks. Confirm that the current and possible leaders support the feature, enable it only on compatible followers, then test election, synchronization, audio, and recovery before acceptance.

What the setting changes

Dante devices use Precision Time Protocol timing messages so followers can align with the elected clock leader. Delay requests help a follower estimate how long timing messages take to cross the network. The default behavior uses multicast; the optional setting makes a follower send its delay requests to the leader by unicast.

Setting	Traffic behavior	Operational consequence
Default delay requests	Followers send multicast delay requests	Simple compatibility, but control traffic grows with follower count
Unicast Delay Requests enabled	Each enabled follower sends requests directly to the leader	Less multicast delay-request traffic when every required device supports it
Mixed compatible network	Some followers use unicast and others remain multicast	Can be valid when support and leader behavior are documented
Unsupported leader path	Enabled followers cannot complete the expected exchange	Followers may fail to synchronize

This setting changes clock-control transport. It does not convert Dante audio flows from multicast to unicast, replace IGMP configuration, fix congestion, or change the receiver audio latency setting.

Decide whether the network needs it

Leave the default in place when the network is small, healthy, and within its measured capacity. Consider Unicast Delay Requests when a large endpoint count creates meaningful multicast clock-control traffic or when the engineered design explicitly requires it.

Start from evidence: inventory device models and firmware, identify the current preferred and elected leaders, measure multicast traffic, and review clock events. Do not enable the option merely because the word “unicast” sounds more efficient.

The Dante clock leader guide explains election and external clock ownership. The network health guide explains how to baseline traffic and clock evidence.

Enable it with a compatibility gate

1. Inventory every possible leader and follower

Record device model, Dante interface generation, firmware, primary and secondary role, current clock status, and whether Controller exposes Unicast Delay Requests. Include devices that may become leader after a failure, not only the leader visible during setup.

2. Prove leader support first

Audinate's Controller guidance says the feature only needs enabling on followers, but the clock leader must support receiving the unicast requests. Check support by confirming the option is available for the device and by consulting current device documentation. If a possible leader does not support it, either keep followers on the default behavior or design and test a supported leader policy.

3. Change a controlled follower group

Save the known-good configuration and event baseline. Enable the setting on a small, representative group of compatible followers. Do not change leader priority, QoS, cabling, firmware, and delay-request mode in the same test window.

4. Verify synchronization and audio

Confirm each changed follower locks to the expected leader, remains stable, and passes identifiable audio. Observe clock status, offset history, event logs, packet errors, and multicast utilization under normal and peak load. Compare results with the baseline rather than relying on a momentary green status.

5. Test election and recovery

Remove or disable the current leader at an approved boundary. Confirm a supported replacement is elected and every enabled follower resynchronizes without an unacceptable mute or repeated warning. Restore the original leader, wait for stability, and repeat on redundant primary and secondary paths when applicable.

Diagnose failure patterns

Evidence	Likely issue	Next controlled check
Changed followers lose sync immediately	Current leader may not support unicast requests	Revert that follower group and verify leader capability
Normal state passes but leader failover fails	A possible replacement leader is incompatible	Test each eligible leader independently
Only one device fails	Firmware, device support, or local path differs	Compare it with a known-good follower of the same role
Multicast load barely changes	Delay requests were not a meaningful share of traffic	Recheck the measurement and leave default behavior if appropriate
Clock warnings continue	Root cause is elsewhere in the timing or network path	Follow the clock-event and offset evidence
Secondary network behaves differently	Support, firmware, or topology differs between paths	Audit both networks as separate failure domains

Do not raise audio latency to conceal clock instability. Receiver latency protects media playout from late audio packets; it does not repair an incompatible PTP exchange.

Acceptance checklist

Every current and possible clock leader has documented support.
Every changed follower has compatible firmware and exposes the setting.
A known-good configuration and clock-event baseline are saved.
Changed followers lock and remain stable under representative load.
Real audio passes to every critical destination.
Multicast utilization is measured before and after.
Leader loss, election, restoration, and redundant-path tests pass.
The rollback procedure restores the previous behavior.
Ownership and the accepted device list are recorded.

If a test produces warnings or unlocks, use the Dante clock sync troubleshooting guide before expanding the change.

Document the clock-control decision

Record why the option is needed, device and firmware inventory, enabled followers, eligible leaders, baseline and post-change utilization, clock events, offset evidence, failover results, owner, and rollback point. A future technician must be able to distinguish an intentional mixed configuration from an incomplete rollout.

In Techrider.live, keep the decision beside the digital-audio network notes and patch. Invite the system engineer to edit the same rider, save the accepted revision, inspect history, and export a PDF for the venue or touring handoff.

FAQ

What are Unicast Delay Requests in Dante?

They make an enabled clock follower send PTP delay-request messages directly to the clock leader instead of sending them as multicast. They affect clock-control traffic, not the transport type of audio subscriptions.

Should I enable Unicast Delay Requests in Dante?

Enable them only when measured scale or a documented network design justifies the change and all required leaders and followers are compatible. A healthy small network usually does not need the extra configuration.

Which Dante devices need Unicast Delay Requests enabled?

Only compatible followers need the option enabled. The current and every possible replacement clock leader must still support receiving the requests.

Can Unicast Delay Requests stop Dante clock sync?

Yes. Audinate warns that enabling the feature on followers while the clock leader does not support it may prevent those devices from synchronizing.

How do I test Dante Unicast Delay Requests?

Baseline the network, change a small follower group, verify clock and audio under load, force an approved leader election, test recovery and redundant paths, then compare multicast utilization and event evidence with the baseline.

Related guides

Basics