Thank you for the question.
In the case that you mention, it would be more appropriate to use Multicast Flows.
A brief explanation:
Unicast describes typically one-to-one connections. In limited circumstances it may be useful to use this for possibly a small number of "multi-unicast" applications. so for example you may want to send the same signal from one device to say two devices.
Multicast is useful when you need to send the signal to many devices.
Under the hood the best way to understand this is as follows:
When a unicast subscription is made- the receiver requests the channel from the transmitter. Once this request is received and the data starts flowing, there is a unique flow between the two devices. If another receiver requests the same channel from the same transmitter, a separate flow is established. This means that two copies of the same data are being sent out. If this is extrapolated to the nth degree, then the transmitter is duplicating a lot of work, and devoting resources to a task that may be somewhat more simple.
Hence the desire for multicast. This time- when a transmitter is told to send multicast, it does just that. the flow is given its own "multicast IP address" and is launched into the network regardless of whether a receiver is requesting this or not. This is the reason why network engineers have a sense of some unease with multicast.
Furthermore, in order for this information to get to places where it "might be needed" the multicast information is "flooded" throughout the network (this means that it goes everywhere). This is the default state of multicast, and with large amounts of multicast data networks can slow down.
This situation is far from ideal- that is why there is a set of standards that deal nicely with this. The case that "it is nice to have the transmitter only doing the right amount of work" and "it would be ideal if this could happen, without disturbing the entire network" would be ideal. This is achieved by using IGMP. All Dante devices have IGMP join/leave implemented upon them. This means that when a Dante enabled receiver subscribes to a particular multicast flow it issues a "join" message. This is a small bit of data that if picked up by a switch in the network, that is listening for this, gives the details of what the receiver wants.
A managed switch with IGMP snooping enabled is able to look at these "join" messages, and if configured in the right way, only allow the right multicast data out of the switch port that has a device requesting this data. This in turn means that other switch ports that do not have devices requesting multicast data attached do not forward irrelevant data effectively to nowhere. This process is called registering multicast.
A switch will typically have an option setting (often per port) that allows you to set a rule for what it should do with unregistered multicast. This is normally expressed as "filtering" or "flooding". Filtering means- "if there is no device attached to this port, requesting multicast data that is available- then do not pass multicast out of the port" remember the switch may have lots of different multicast messages- in filter mode it will only pass the useful ones- requested (registered) by the end points attached to that specific port. For the purposes of clarity we mean attached to a specific port to be; anything downstream, so this could be a device that is several switch hops away- the path as far as our IGMP switch is concerned is still out of one specific switch port. In flooding mode the switch simply watches the data, and doesn't get involved in "pruning" the multicast tree. It does nothing to cut down the amount of multicast information going out of the specified switch port. This can be useful for uplinks on a large network, and for diagnostic purposes.
I hope this answers your questions.
Best Wishes
Kieran