Dante unicast vs multicast : choisir le bon flux audio

TL;DR — Dante utilise l’unicast par défaut : un flux média sert un seul appareil récepteur. Le multicast envoie un flux configuré que plusieurs récepteurs peuvent rejoindre. Utilisez l’unicast pour les souscriptions point à point classiques ; envisagez le multicast lorsque plusieurs récepteurs ont besoin des mêmes canaux d’un transmetteur ou lorsque la capacité de flux du transmetteur devient la limite. Le multicast peut se propager sur chaque lien réseau s’il n’est pas correctement géré avec IGMP. Comptez les récepteurs, les flux, les canaux et la bande passante des liens, puis testez les destinations réelles avant de documenter le choix.

L’unicast et le multicast résolvent des problèmes de fanout différents

Une souscription Dante relie un canal de réception à un canal d’émission. Le réseau transporte ces souscriptions sous forme de flux. Un flux unicast va d’un transmetteur vers un seul appareil récepteur. Un flux multicast est créé au niveau du transmetteur et peut servir plusieurs appareils récepteurs.

Ne confondez pas le multicast média avec la découverte Dante et le trafic d’horloge. Un réseau peut utiliser des protocoles multicast même si toutes les souscriptions audio sont en unicast. La décision de production ici consiste à savoir si certains canaux média doivent être placés dans un flux d’émission Dante multicast.

Commencez par l’unicast pour les souscriptions ordinaires

L’unicast est le défaut le plus simple, car Dante Controller crée et supprime les flux nécessaires au fur et à mesure que les récepteurs se souscrivent et se désabonnent. Le trafic est dirigé vers l’appareil récepteur au lieu d’être distribué volontairement à plusieurs auditeurs.

Utilisez l’unicast lorsque :

• un ou deux appareils ont besoin d’une source ;
• des groupes de récepteurs ont besoin de jeux de canaux différents ;
• le transmetteur dispose d’assez de flux disponibles ;
• le trajet traverse un lien où un trafic multicast inutile serait coûteux ;
• le système est assez petit pour que le routage automatique soit plus simple à contrôler.

Un flux unicast transporte généralement plusieurs canaux audio d’un transmetteur vers un récepteur, mais les capacités exactes en matière de flux et de canaux dépendent de l’appareil émetteur et du firmware. Ne dimensionnez pas un spectacle sur la base d’un chiffre générique seul. Vérifiez la capacité de flux d’émission annoncée de l’appareil dans Dante Controller et confirmez les routes prévues sur le matériel réel.

Utilisez le multicast lorsque plusieurs récepteurs ont besoin des mêmes canaux

Le multicast peut réduire le fanout côté transmetteur lorsque le même programme doit atteindre de nombreuses destinations. Un seul flux multicast configuré peut alimenter des amplificateurs, des enregistreurs, des interfaces broadcast et des dispositifs de monitoring qui le rejoignent. Ajouter un récepteur de plus ne nécessite pas de copie supplémentaire depuis le transmetteur.

Cas adaptés :

• une paire programme distribuée à de nombreux points d’amplification ;
• un canal de paging ou d’annonce requis par plusieurs zones ;
• un retour broadcast partagé par plusieurs appareils récepteurs ;
• une source répétée qui dépasserait sinon la capacité de flux du transmetteur ;
• des flux AES67 ou autres flux RTP dont la conception d’interopérabilité exige le multicast.

Ne créez pas un seul gros flux simplement parce que le multicast existe. Regroupez uniquement les canaux qui doivent réellement voyager ensemble pour les récepteurs. Un récepteur qui rejoint un seul canal d’un flux peut entraîner le transport de tout le flux sur ce trajet. Des groupes plus petits et intentionnels sont plus faciles à nommer, mesurer et supprimer en sécurité.

Comptez le fanout avant de modifier le routage

Établissez une matrice des récepteurs avant de configurer le multicast :

Pour chaque transmetteur, notez les flux d’émission disponibles, les flux en cours, les récepteurs prévus, les canaux par récepteur, la vitesse de lien et la bande passante mesurée. Une alerte de fanout signifie que la route mérite un examen ; elle ne prouve pas que le multicast est automatiquement sûr. Le nouveau trafic multicast doit tout de même traverser chaque lien requis.

Contrôlez le multicast au niveau de la commutation

Sans gestion du multicast, un switch peut diffuser les médias vers des ports qui ne les ont jamais demandés. Cela peut gaspiller de la capacité sur des liens 100 Mbps, des ponts Wi-Fi, des ordinateurs de contrôle et des appareils aux interfaces limitées.

Les réseaux managés utilisent souvent IGMP snooping pour que les switchs identifient les ports qui ont demandé un groupe multicast. Le réseau a aussi besoin d’une fonction querier correctement conçue pour que l’état d’appartenance reste valide. Les détails de configuration varient selon la plate-forme de switch, la topologie et les VLAN ; suivez donc le design réseau approuvé plutôt que de copier les menus d’un constructeur.

Vérifiez ces points de contrôle :

1. Quel switch ou routeur porte le rôle de querier IGMP ?
2. Le snooping est-il activé de façon cohérente sur le réseau concerné ?
3. Tous les trunks et ports d’accès transportent-ils bien les groupes attendus ?
4. Les chemins Wi-Fi, 100 Mbps, de contrôle ou d’uplink sont-ils protégés contre les médias indésirables ?
5. Le réseau redondant reproduit-il indépendamment la configuration requise ?

Le guide Dante redondant versus mode commuté explique pourquoi les réseaux primaire et secondaire doivent rester séparés. La configuration multicast ne justifie pas de les relier.

Testez le routage et son comportement en cas de panne

1. Enregistrez l’état de référence

Notez les noms des appareils, les souscriptions, les flux actifs, la fréquence d’échantillonnage, la latence, le leader d’horloge, les groupes multicast, la configuration des switchs et la bande passante avant toute modification.

2. Validez l’état unicast

Confirmez que chaque destination reçoit les bons canaux. Notez l’utilisation des flux du transmetteur et la bande passante sur chaque lien important.

3. Créez uniquement le flux multicast prévu

Choisissez les canaux exacts du transmetteur, nommez l’objectif et observez quels récepteurs existants passent de l’unicast au multicast. Ne supposez pas que la transition a eu lieu ; inspectez l’état des souscriptions et des flux.

4. Vérifiez chaque segment réseau

Mesurez les ports de switch et les liens contraints avec tous les récepteurs actifs. Confirmez que le multicast n’apparaît que là où cela est requis lorsque la gestion IGMP fait partie du design.

5. Retirez et rétablissez les récepteurs

Déconnectez ou désabonnez une destination à la fois. Confirmez que les récepteurs restants continuent de fonctionner, que les appartenances se mettent à jour correctement et que l’endpoint retiré ne laisse pas d’état de trafic ou de routage inattendu.

6. Répétez le retour arrière

Avant de supprimer un flux multicast, calculez si le transmetteur peut recréer tous les flux unicast résultants. Supprimez les routes dans un ordre contrôlé si nécessaire, rétablissez l’état de référence et vérifiez à nouveau l’audio.

Inscrivez la responsabilité des flux dans la fiche technique

Un transfert utile nomme le transmetteur, les canaux, le type de flux, les récepteurs, le propriétaire du switch, la conception IGMP, les liens contraints, la référence de bande passante, la fenêtre de test et le retour arrière. « Utiliser Dante multicast » n’est pas une consigne exécutable.

Dans Techrider.live, alignez les noms de flux avec les listes d’entrées et de sorties, invitez les ingénieurs système et broadcast à modifier la même fiche technique, enregistrez la matrice de récepteurs acceptée, consultez l’historique après une modification de routage et exportez un PDF daté pour le load-in.

Checklist des flux Dante

• La capacité réelle de flux de chaque transmetteur est connue.
• Les récepteurs qui ont besoin des mêmes canaux sont listés.
• L’unicast est conservé lorsque le fanout est faible ou que les jeux de canaux diffèrent.
• Les groupes multicast ne contiennent que des canaux qui vont ensemble.
• L’IGMP snooping et le propriétaire du querier sont documentés lorsque c’est utilisé.
• La bande passante est mesurée sur les uplinks et les interfaces contraintes.
• L’état des souscriptions, l’horloge, la latence, les erreurs, les pertes et le retour arrière sont testés.

FAQ

Quelle est la différence entre Dante unicast et multicast ?

L’unicast envoie un flux média d’un transmetteur vers un seul appareil récepteur. Le multicast crée un flux unique côté transmetteur que plusieurs appareils récepteurs peuvent rejoindre. L’unicast est automatique par défaut ; le multicast est configuré volontairement.

Quand faut-il utiliser le multicast dans Dante ?

Envisagez le multicast lorsque plusieurs récepteurs ont besoin des mêmes canaux, que le transmetteur approche de sa limite de flux ou qu’une conception d’interopérabilité l’exige. Vérifiez le comportement des switchs et la bande passante avant de modifier le routage.

Dante utilise-t-il le multicast par défaut ?

Les souscriptions média Dante utilisent l’unicast par défaut. La découverte et l’horloge Dante utilisent aussi des protocoles réseau qui incluent du trafic multicast, mais cela est distinct du choix d’un flux média multicast.

Le multicast Dante nécessite-t-il l’IGMP snooping ?

L’audio peut circuler sans snooping, mais le multicast peut alors se répandre vers des ports de switch inutiles. Sur les réseaux de production managés, un IGMP snooping correctement conçu et un querier maintiennent généralement les médias sur les liens requis. Suivez le design du switch et du système.

Comment tester un audio Dante en multicast ?

Enregistrez l’état de référence, vérifiez chaque récepteur, inspectez l’état des flux, mesurez tous les liens importants, confirmez le pruning IGMP là où il est attendu, retirez puis rétablissez les destinations et répétez un retour contrôlé vers l’unicast.

Rendez le fanout visible avant le load-in

Créez une seule fiche technique qui nomme chaque canal source, récepteur, type de flux, limite de switch, test, responsable et retour arrière avant que des souscriptions répétées n’occupent le réseau.