Who this guide is for

This guide is for AV integrators, IT managers, and system designers planning a Dante network that will grow beyond a single, small switch, multiple rooms, buildings, or an entire campus. It explains why device counts and subnet boundaries matter to Dante's performance, and what tools and design practices keep large systems reliable.

1. The short version

A single Dante subnet has a real, hardware-ceiling on device count, and it comes from PTP clocking. One device is elected the PTP clock leader on each subnet, and every other device continuously exchanges timing packets with it to stay sample synchronised. The leader's hardware sets a hard limit on how many followers it can service accurately: 250 followers for high-capability Dante chipsets, 40 for low-level ones. On top of that, cross-subnet audio consumes unicast flow capacity, and discovery/clocking doesn't cross subnets. Audinate's answer is centralised management software — Dante Domain Manager or Dante Director — combined with deliberate subnetting and boundary clocking. This guide walks through why and what to do about it.

2. Why 250 devices: the PTP clocking limit

The technical reason that a Dante subnet has a device ceiling is based in how Precision Time Protocol (PTP) clock distribution works.

2.1 How Dante PTP clocking works

Every Dante device synchronises its clock using PTP. One device on the subnet is elected clock leader (via the Best Leader Clock Algorithm); every other device is a follower. Synchronisation is not a one-time handshake. Clocks drift continuously, so the process runs as a permanent control loop:

• The leader multicasts Sync/Follow-up messages to all followers so they can align clock time and speed.
• Every follower periodically sends a multicast Delay Request back to the leader to measure network path delay.
• The leader must hardware-timestamp each incoming Delay Request the instant it arrives, then promptly generate and return a Delay Response with that timestamp for every follower, continuously.

2.2 Why the leader's hardware sets the ceiling

PTP's delay calculation assumes the network path delay is symmetric. If the leader queues incoming Delay Requests instead of timestamping them immediately because it's servicing too many followers at once, that queuing shows up as asymmetric delay, which corrupts the follower's offset calculation and degrades sync accuracy. The number of followers a leader can service without this breakdown is a function of that specific chipset's hardware timestamping and processing throughput, not a configurable setting.

Audinate publishes exactly this ceiling, split by chipset capability:

So "250 devices" is the follower capacity of a subnet whose elected leader is a high-capability chipset. If an low-capability chipset device (e.g. an UltimoX or AVIO product) ends up winning the clock-leader election on that subnet instead, the real ceiling for reliable sync drops to 40 devices. 

2.3 What happens when you exceed it

Exceeding follower capacity does not cause a graceful degradation; Dante devices will simply mute rather than play out-of-sync audio. Dante has defined jitter tolerances: up to 250 µs for hardware devices, and up to 1ms for software devices like Dante Virtual Soundcard). When you push past the leader's servicing capacity, delay-response latency grows, and jitter exceeds tolerance. Large subnets also make PTP inherently "chattier": because Delay Request/Response traffic goes to a shared multicast address, every follower's timing exchange is visible to every other device on the subnet, not just to the leader. This is part of why a single flat subnets becomes more failure-prone as it grows, even before you reach the hard follower count.

3. Other constraints that compound at scale

3.1 Flows: how Dante moves audio

Dante packages audio into flows to keep network overhead low. There are two kinds:

• Unicast flows: point-to-point from one transmitter to one receiver. One unicast flow can contain up to 4 channels and uses about 6 Mbps of bandwidth. Dante audio flows are unicast by default.
• Multicast flows: one transmitter to many receivers at once, using roughly 1.5 Mbps per channel. Useful for fan-out scenarios (one source feeding many zones). You can create multicast flows in Device View in Dante Controller.

Every device supports a finite number of flows and how many varies by Dante module.  low-capacity chipsets (Ultimo and AVIO devices) support between 2 and 4 flows, whereas high-capacity chipsets (Brooklyn and Broadway) can support 32×32 or 64×64). Critically, audio sent between devices on different subnets must use unicast flows. A single multicast transmit flow cannot be relied upon to cross subnet/VLAN boundaries and reach cross-subnet receivers the way it does within one subnet. If a design routes many channels between subnets, it can burn through a device's flow budget far faster than the same channel count would within one flat network.

3.2 Discovery and clocking do not cross subnets without a Dante management platform

This is a limitation of native Dante operation, rather than a simple configuration setting. Native Dante device discovery uses multicast DNS (subscribed at 224.0.0.251:5353), and native Dante clocking uses multicast PTP, with one clock leader elected per subnet. Standard IP routers do not forward this multicast traffic between subnets, and there is no native Dante mechanism that makes them do so. In a native Dante deployment, a device on Subnet A cannot discover or exchange Dante audio and clocking with a device on Subnet B, even if standard IP routing exists. Cross-subnet operation requires Dante Domain Manager or Dante Director, regardless of whether the subnets are IP-routable to each other.

This is precisely why unicast mechanisms exist to bridge subnets under within a managed Domain  ( using a management platform such as Dante Domain Manager or Dante Director):

• Simply enabling Layer 3 routing between VLANs or subnets does not allow native Dante devices to communicate across them. Cross-subnet Dante requires Dante Domain Manager or Dante Director to provide discovery, clocking and control.
• Discovery: DDM replaces multicast discovery with DNS-based service discovery (unicast DNS-SD using standard DNS records), allowing devices on different subnets to locate the DDM server and each other. 
• Clocking is bridged using unicast boundary clocks: one device per subnet is elected (or assigned) as that subnet's boundary clock, receives unicast PTP from the domain's Grand Leader, and then re-distributes multicast PTP to the other devices within its own subnet.

3.3 Multicast and broadcast domain size

Even within a single subnet, growing the device count grows the volume of multicast housekeeping traffic (PTP sync at ~4 Hz, mDNS, control/monitoring). This is manageable well into the hundreds of devices on well-configured Gigabit infrastructure, but it's the reason IT best practice and Audinate's own guidance favour right-sized subnets, IGMP management, and dedicated VLANs for Dante traffic rather than one enormous flat broadcast domain shared with unrelated network traffic.

4. What to do for larger networks

4.1 Use Dante Domain Manager or Dante Director for centralized management 

For any system that spans more than one subnet, or more than a handful of rooms, use one of Audinate's management platforms rather than trying to bridge subnets with routing alone:

Pricing and exact tier limits are subject to change — confirm current figures with Audinate or your Dante reseller before finalizing a system design.

4.2 Size and split subnets around clock leader capacity

• Group devices logically by room, floor, building, or function (e.g., background music vs. paging)  into separate subnets, rather than one unmanageably large flat group.
• Budget flows before you route check each device's transmit/receive flow capacity in Dante Controller (Device View → Transmit/Receive tabs) and design cross-subnet channel counts with that ceiling in mind.
• Favor unicast for point-to-point cross-subnet links and reserve multicast for genuine one-to-many fan-out within a subnet.
• Keep each subnet at or under its clock leader's follower capacity 250 devices if the leader will be a Brooklyn II/Broadway/HC/PCIe/IP Core-class device, only 40 if it will be an UltimoX/AVIO/Dante Pro S1-class device. If a subnet is approaching those limits, plan to split it before capacity becomes a constraint.
• Use boundary clocking for multi-subnet domains in Dante Domain Manager or Dante Director, one Grand Leader is elected for the domain, and one boundary clock is elected (or assigned) per subnet. The boundary clock receives unicast PTP timing originating from the domain's Grand Leader and re-distributes multicast PTP locally, keeping each subnet's own follower count within its local leader's capacity. DDM's Auto-Configure can assign this for you; a backup boundary clock per subnet is recommended.
• On large subnets, deliberately assign the preferred clock leader (or boundary clock) to a known high-capability device rather than relying entirely on automatic BMCA election. Although high-capability Dante devices will normally be preferred because they advertise higher-quality clocks, explicitly selecting the leader avoids the possibility of an unsuitable device becoming leader after configuration changes or hardware replacement.
• Reduce PTP "chatter" on large subnets Reduce unnecessary multicast traffic on large subnets by enabling IGMP snooping, using appropriate QoS, and following Audinate's recommendations for boundary clocking and Clock Zoning where supported. In some instances, you can also enable ‘Unicast delay requests’ in the Device Config tab in Dante Controller on the following devices to reduce multicast traffic. Unicast delay requests is a feature that changes the way Dante devices measure network timing. Normally, clock follower devices send multicast delay request messages to the clock leader to calculate the network transit time. When unicast delay requests is enabled, these messages are sent as unicast instead, reducing multicast traffic on the network and improving scalability, especially in larger Dante systems with many devices. Note that this feature is not available for all devices and the leader clock must support it too. From Dante Controller 4.18, this feature is supported for both v1 and v2. Earlier Dante Controller versions only support this feature for v1.

4.3 Underlying network design (applies at any scale, more critical at large scale)

4.4 External PTP clocks

For larger enterprises, broadcast, or campus deployments, Dante supports synchronisation to an external PTP Grand Leader. This provides a stable, network-wide timing reference and avoids relying on a single Dante endpoint as the primary clock source.

For wide-area deployments spanning multiple sites or buildings, GPS-disciplined clocks (such as TimeMachines units) can provide a common timing reference across geographically separated Dante networks. This is particularly useful for shared audio between sites where a single PTP leader cannot serve the entire infrastructure: each site can lock to GPS independently, ensuring all locations share the same time base without requiring direct PTP communication between them.

PTP-aware switches operating as Boundary Clocks can improve timing performance on larger networks by regenerating PTP timing for downstream devices, reducing clock load on the Grand Leader. 

⚠️ Note on Transparent Clocks: While Transparent Clock–capable switches are designed to compensate for switch forwarding delays, Dante devices have known compatibility issues with Transparent Clocking enabled on some network switches. Boundary Clock mode is the recommended approach for PTP-aware switch deployments with Dante. 

External PTP infrastructure does not remove Dante's follower limits, and each subnet is still constrained by the capacity of its local Dante clock leader or boundary clock. External timing should therefore be considered a complement to, rather than a replacement for, good subnet design and clock planning.

5. Planning checklist

• Estimate total device count per subnet and identify which chipset class will hold the clock leader / boundary clock role (40-follower vs. 250-follower hardware).
• Confirm switches support QoS (DSCP, strict priority, 4 queues), can disable EEE, and support IGMP snooping/querier if needed — misconfigured IGMP snooping and EEE are top causes of PTP sync failure.
• Map out how many channels must cross subnet boundaries, and check receiving/transmitting devices' unicast flow capacity against that number.
• Split any subnet that is approaching its clock leader's follower capacity and deliberately assign the leader/boundary clock rather than relying on automatic election.
• Document VLAN boundaries and confirm multicast is explicitly blocked between unrelated VLANs.
• Assign boundary clock devices (with backups) per subnet if spanning a domain across subnets and consider PTPv2-aware switches or DDM Clock Zoning on very large deployments.
• Decide between Dante Domain Manager (on-premises, single campus) and Dante Director (cloud, multi-site) based on where the system will be hosted and managed.
• Choose a DDM licensing tier (or Director plan) based on total devices and domains needed.