Dante and AES67: Audio, Flows, and Clocking

Why an AV engineer should care

Dante makes a channel subscription look simple: choose a transmitter, choose a receiver, and make the crosspoint. The network still has real work to do. It carries audio flows, elects a clock leader, preserves enough delivery margin, and—when redundancy is used—keeps two isolated paths healthy.

AES67 adds a useful interoperability option, but it is not a promise that every Dante feature, control function, or channel format will work with every other audio-over-IP product.

Learning objectives

By the end of this lesson, you should be able to:

• Distinguish Dante channels, subscriptions, and network flows.
• Explain why unicast and multicast have different scaling limits.
• Describe PTP clock election and receiver latency in practical terms.
• Recognize what Dante redundancy requires.
• Scope AES67 as a tested audio-transport interoperability workflow.

---

1. Channels are not always flows

A Dante transmitter exposes channels: logical audio outputs such as console input 1 or DSP program left. A receiver exposes input channels. A subscription connects one transmitter channel to one receiver channel.

Those subscriptions are carried in network flows. A flow can contain one or more audio channels, depending on the device and configuration. That distinction matters for bandwidth and fan-out: a routing matrix may show many channel crosspoints while the switch forwards a smaller number of packet flows.

Do not estimate a system from channel count alone. Check the device documentation for channel capacity, flow limits, supported sample rates, bit depth, packet time, and whether a required route becomes unicast or multicast.

2. Unicast and multicast answer different problems

Dante normally uses unicast for a small number of receivers: the sender creates a flow addressed to a particular receiver. This is efficient when one or a few destinations need the audio.

When a transmitter must reach many receivers, multicast can avoid creating a separate sender flow for every destination. The sender emits one multicast flow and a correctly configured network forwards it only to interested ports. Multicast changes the distribution point; it does not make bandwidth disappear. Each receiver-facing port and each uplink carrying that group still carries the complete flow.

Audinate documents both the difference between unicast and multicast routing and the sender fan-out limits that can require multicast. (Dante Controller: routing media, fan-out)

Practical example: one lobby program feed

A DSP sends a stereo program feed to two amplifiers and a recorder. Unicast may be entirely appropriate if the transmitter supports the needed flows. If that same feed must reach twenty amplifiers across several access switches, assess multicast deliberately: enable IGMP snooping, ensure there is an active querier where needed, and calculate every uplink carrying the group.

Never convert every Dante flow to multicast merely because multicast sounds scalable. Unnecessary multicast expands the part of the network that must carry and manage real-time traffic.

3. PTP gives sampled audio a common time

Digital audio devices must agree on time. Dante uses Precision Time Protocol (PTP) to elect a clock leader and synchronize followers. The elected leader is a role, not a permanent property of a particular box. A preferred-master setting can influence the election, but it should be used intentionally and verified after topology changes.

A clock problem can sound like clicks, dropouts, or unstable subscriptions, but do not diagnose it from sound alone. Check clock status, interface link state, VLAN/path consistency, and device logs before changing priorities.

For AES67 interoperability, PTP compatibility is a central requirement. In Dante Domain Manager, AES67 mode uses PTPv2 domain 0; enabling AES67 also requires compatible device and domain settings. Not every Dante device supports AES67. (Audinate AES67 and SMPTE domains)

4. Latency is a receiver safety margin

Receiver latency is the time a receiver reserves to absorb network delay variation before it must play audio. It is not a score for system quality and it is not necessarily the total end-to-end audio delay.

A very low setting can work on a short, quiet bench network and fail after the system gains switch hops, multicast load, or ordinary operational traffic. Raising the setting gives the network more arrival margin; it does not repair packet loss, a bad link, or a saturated uplink.

Choose a setting supported by the product and topology, then verify it under realistic load. If the only stable result requires a surprisingly high setting, treat that as evidence to investigate the network path.

5. Redundancy means two separate networks

A redundant Dante device has primary and secondary interfaces intended for separate, non-interconnected networks. They are not two ports to aggregate, bridge, or attach to the same switch fabric. The device transmits on both paths and uses the surviving copy if one path fails.

A useful commissioning test is physical and observable: establish a known-good subscription, remove one primary-path link, confirm uninterrupted audio and expected secondary status, restore it, then repeat for the secondary path. Test only in an approved maintenance window.

Redundancy does not protect a device with one network interface, a shared power failure, a common rack fault, or an accidental bridge between the two networks. Document those remaining failure modes honestly.

6. What AES67 does—and does not—standardize

AES67 specifies interoperable high-performance audio transport using RTP and PTP. It is valuable when compatible equipment from different ecosystems must exchange audio. It does not standardize every vendor's discovery, management, routing UI, redundant-network behavior, or every possible media parameter.

Treat an AES67 connection as an integration task:

1. Confirm both products explicitly support AES67 in the intended firmware and mode.
2. Match sample rate, channel count, packet time, multicast address/port conventions, and PTP settings.
3. Confirm the required network scope and multicast behavior.
4. Subscribe and verify audio, then test restart and clock-leader changes.
5. Record the working settings and versions.

Dante-to-Dante audio continues to use Dante transport even when an AES67-capable domain is configured; AES67 is for the compatible interoperation boundary. (Audinate DDM guide)

Public-facing design and commissioning takeaway

A useful audio-over-IP schedule records:

• Device model, firmware, sample rate, and channel count
• Required transmitter flows and expected receiver fan-out
• Unicast versus multicast intent
• VLAN and PTP clock path
• Receiver latency setting and the reason for it
• Primary and secondary network paths, when used
• AES67 compatibility settings and a test result
• Normal and failure-path uplink load

Practical exercise

On a small Dante system, identify one subscription and answer:

1. Which transmitter channel and receiver channel are connected?
2. Is the traffic unicast or multicast?
3. Which device is the current PTP clock leader?
4. What receiver latency is configured?
5. What link or switch failure would interrupt this route?

Compact glossary

• Channel: One logical audio input or output.
• Subscription: A requested transmitter-to-receiver channel connection.
• Flow: Packet stream that carries one or more channels.
• PTP: Precision Time Protocol, used for clock synchronization.
• Clock leader: Device currently elected as the timing reference.
• AES67: Standard for interoperable high-performance audio-over-IP transport.
• Fan-out: Number of receivers served by a transmitter or flow.

Review questions

1. Why is channel count alone not enough to estimate Dante network load?
2. What does multicast reduce, and what does it not reduce?
3. Does enabling AES67 make every Dante feature interoperable?

Answers

1. Channels are mapped into flows, and the device's flow limits and media settings determine the actual packet traffic.
2. It can reduce duplicate sender flows; it does not reduce the bitrate carried by links and receiver ports that need the flow.
3. No. It enables compatible audio transport; discovery, control, parameter compatibility, and product support still need verification.