Dante Unicast vs Multicast: Choose the Right Audio Flow

TL;DR — Dante uses unicast by default: one media flow serves one receiving device. Multicast sends one configured flow that multiple receivers can join. Use unicast for ordinary point-to-point subscriptions; consider multicast when several receivers need the same transmitter channels or transmit-flow capacity becomes the limit. Multicast can spread across every network link unless correctly managed with IGMP. Count receivers, flows, channels, and link bandwidth, then test the real destinations before documenting the choice.

Unicast and multicast solve different fanout problems

A Dante subscription connects a receiving channel to a transmitting channel. The network carries those subscriptions in flows. A unicast flow goes from one transmitter to one receiving device. A multicast flow is created at the transmitter and can serve multiple receiving devices.

Do not confuse media multicast with Dante discovery and clock traffic. A network can use multicast protocols even when every audio subscription is unicast. The production decision here is whether particular media channels should be placed in a Dante multicast transmit flow.

Start with unicast for ordinary subscriptions

Unicast is the simplest default because Dante Controller creates and removes the required flows as receivers subscribe and unsubscribe. Traffic is directed toward the receiving device rather than intentionally distributed to many listeners.

Use unicast when:

• one or two devices need a source;
• receiver groups need different channel sets;
• the transmitter has enough available flows;
• the path crosses a link where unnecessary multicast traffic would be costly;
• the system is small enough that automatic routing is easier to inspect.

A unicast flow commonly carries several audio channels from one transmitter to one receiver, but exact flow and channel capacities depend on the transmitting device and firmware. Do not calculate a show from a generic number alone. Check the device's advertised transmit-flow capacity in Dante Controller and confirm the planned routes on the actual hardware.

Use multicast when many receivers need the same channels

Multicast can reduce transmitter fanout when the same programme must reach many destinations. One configured multicast flow may feed amplifiers, recorders, broadcast interfaces, and monitoring devices that join it. Adding another receiver does not require another copy from the transmitter.

Good candidates include:

• a programme pair distributed to many amplifier endpoints;
• a paging or announcement channel required by many zones;
• a broadcast feed shared by several receiving devices;
• a repeated source that would otherwise exceed the transmitter's flow capacity;
• AES67 or other RTP flows whose interoperability design requires multicast.

Do not create one giant flow merely because multicast is available. Group only the channels that receivers genuinely need together. A receiver joining one channel in a flow may cause the network to carry the whole flow along that path. Smaller, purposeful groups are easier to name, measure, and remove safely.

Count fanout before changing the route

Build a receiver matrix before configuring multicast:

For each transmitter, record its available transmit flows, current flows, planned receivers, channels per receiver, link speed, and measured bandwidth. A fanout warning means the route deserves review; it does not prove multicast is automatically safe. The new multicast traffic still has to cross every required link.

Control multicast at the switching layer

Without multicast management, a switch may forward media to ports that never requested it. That can waste capacity on 100 Mbps links, Wi-Fi bridges, control computers, and devices with limited interfaces.

Managed networks commonly use IGMP snooping so switches learn which ports requested a multicast group. The network also needs a correctly designed querier function so membership state remains valid. Configuration details vary by switch platform, topology, and VLAN, so follow the approved network design rather than copying one vendor's menu settings.

Check these boundaries:

1. Which switch or router owns the IGMP querier role?
2. Is snooping enabled consistently on the relevant network?
3. Do all trunks and access ports carry the intended group?
4. Are wireless, 100 Mbps, control, or uplink paths protected from unwanted media?
5. Does the redundant network repeat the required configuration independently?

The Dante redundant versus switched guide explains why primary and secondary networks must remain separate. Multicast configuration does not justify joining them.

Test the route and its failure behavior

1. Save the baseline

Record device names, subscriptions, active flows, sample rate, latency, clock leader, multicast groups, switch configuration, and bandwidth before making changes.

2. Prove the unicast state

Confirm every destination receives the correct channels. Note transmitter flow use and bandwidth on each important link.

3. Create only the intended multicast flow

Choose the exact transmitter channels, name the purpose, and observe which existing receivers move from unicast to multicast. Do not assume the transition happened; inspect subscription and flow status.

4. Check every network segment

Measure switch ports and constrained links with all receivers active. Confirm multicast appears only where required when IGMP management is part of the design.

5. Remove and restore receivers

Disconnect or unsubscribe one destination at a time. Confirm remaining receivers continue, membership updates correctly, and the removed endpoint does not leave an unexpected traffic or routing state.

6. Rehearse rollback

Before deleting a multicast flow, calculate whether the transmitter can recreate all resulting unicast flows. Remove routes in a controlled order if necessary, restore the baseline, and verify audio again.

Put flow ownership in the Rider

A useful handoff names the transmitter, channels, flow type, receivers, switch owner, IGMP design, constrained links, bandwidth baseline, test window, and rollback. “Use Dante multicast” is not a buildable instruction.

In Techrider.live, align flow names with the input and output lists, invite the system and broadcast engineers to edit the same Rider, save the accepted receiver matrix, inspect history after a routing change, and export a dated PDF for load-in.

Dante flow checklist

• Every transmitter's actual flow capacity is known.
• Receivers needing identical channels are listed.
• Unicast is retained where fanout is small or channel sets differ.
• Multicast groups contain only channels that belong together.
• IGMP snooping and querier ownership are documented where used.
• Bandwidth is measured on uplinks and constrained interfaces.
• Subscription status, clock, latency, errors, loss, and rollback are tested.

FAQ

What is the difference between Dante unicast and multicast?

Unicast sends a media flow from one transmitter to one receiving device. Multicast creates one transmitter flow that multiple receiving devices can join. Unicast is automatic by default; multicast is configured deliberately.

When should you use multicast in Dante?

Consider multicast when several receivers need the same channels, the transmitter is approaching its flow limit, or an interoperability design requires it. Verify switch behavior and bandwidth before changing the route.

Does Dante use multicast by default?

Dante media subscriptions use unicast by default. Dante discovery and clocking also use network protocols that include multicast traffic, but that is separate from choosing a multicast media flow.

Does Dante multicast require IGMP snooping?

Audio can pass without snooping, but multicast may then flood unnecessary switch ports. On managed production networks, correctly designed IGMP snooping and a querier commonly keep media on required links. Follow the switch and system design.

How do you test Dante multicast audio?

Save the baseline, verify every receiver, inspect flow status, measure all important links, confirm IGMP pruning where expected, remove and restore destinations, and rehearse a controlled return to unicast.

Make fanout visible before load-in

Create one Rider that names every source channel, receiver, flow type, switch boundary, test, owner, and rollback before repeated subscriptions consume the network.