Dante vs AES67 : planifier un réseau audio interopérable

En bref — Dante est une plateforme commerciale complète de réseau audio ; AES67 est une norme d’interopérabilité pour des flux audio-over-IP compatibles. Les appareils Dante pris en charge peuvent échanger de l’audio AES67 RTP multicast avec des terminaux AES67 non-Dante, mais l’activation du mode n’est qu’un début. Les terminaux doivent aussi partager des formats audio compatibles, un adressage multicast, un clocking PTPv2, une politique réseau et des abonnements testés. Conservez Dante natif pour les liaisons Dante-à-Dante, sauf si la conception exige explicitement une frontière AES67.

Dante et AES67 répondent à des besoins de taille différente

Dante et AES67 sont souvent comparés comme s’il s’agissait de deux produits interchangeables. Ce n’est pas le cas.

Dante fournit la découverte des appareils, le routage, le clocking, la supervision, la configuration et le transport des médias au sein d’un écosystème pris en charge. AES67 définit une façon commune pour des systèmes audio-over-IP professionnels d’échanger des flux audio non compressés. Il ne standardise pas toutes les fonctions de contrôle, de découverte, de sécurité ou de gestion autour de ces flux.

La question pratique n’est donc pas « lequel gagne ? ». C’est « où le système a-t-il besoin d’une frontière audio fondée sur une norme, et qui maîtrise chaque réglage sur cette frontière ? »

Utiliser Dante natif à l’intérieur d’un système Dante

Lorsque les deux extrémités sont des appareils Dante, elles communiquent normalement avec le transport Dante natif même si le mode AES67 est activé. Activer AES67 ne convertit pas toutes les routes en AES67 et n’améliore pas un abonnement Dante-à-Dante ordinaire.

Utilisez le chemin natif lorsqu’il satisfait déjà l’exigence de production. Il conserve la dénomination, le routage, la supervision et le workflow de récupération attendus de Dante. Ajoutez AES67 lorsqu’un terminal non-Dante compatible doit envoyer ou recevoir de l’audio à travers une interface conçue volontairement, par exemple une frontière broadcast, AV installé, console, DSP ou enregistrement.

Cette distinction évite une erreur fréquente : modifier un réseau stable uniquement parce que chaque appareil propose une option d’interopérabilité.

Vérifier que chaque terminal prend en charge le mode requis

La prise en charge AES67 est une capacité de l’appareil, pas une garantie attachée à chaque port réseau. Avant de faire avancer le show, inventoriez :

• le produit et l’interface exacts ;
• le firmware installé et la version du logiciel Dante ;
• le mode RTP ou AES67 pris en charge ;
• les fréquences d’échantillonnage, le nombre de canaux et le format de paquets pris en charge ;
• les restrictions d’adresse multicast ;
• les options de clock PTPv2 et le comportement du domaine ;
• si le changement de mode exige un redémarrage ;
• comment le terminal non-Dante annonce ou accepte le flux.

Dans les versions actuelles de Dante Controller, les appareils compatibles exposent des contrôles de configuration RTP ou AES67. Les produits plus anciens peuvent avoir des limites plus étroites d’adresse, de flow ou de clocking. Utilisez la documentation correspondant au firmware déployé plutôt que de supposer qu’un appareil validé représente toute la flotte.

Traiter la route AES67 comme un flux multicast défini

L’interopérabilité AES67 utilise des flux RTP multicast. Un émetteur crée un flux avec un format audio, une adresse multicast de destination, un port UDP et un comportement temporel. Le récepteur doit prendre en charge ces valeurs et rejoindre le même flux.

Définissez le flux avant de créer des abonnements :

Certaines implémentations Dante ne reçoivent des flux AES67 que dans certaines plages multicast. Un abonnement peut aussi sembler accepté alors que l’audio ne passe pas si le préfixe RTP configuré du récepteur ne correspond pas au flux transmis. Notez les exigences réellement déployées au lieu de recopier un exemple d’adresse générique.

Pour la décision de fanout plus large, voir Dante unicast versus multicast.

Construire le clocking PTPv2 comme un chantier à part entière

AES67 dépend du timing PTPv2. Les réseaux Dante natifs ont leur propre comportement d’élection de clock, donc une conception interopérable doit définir explicitement comment les appareils concernés atteignent une référence PTPv2 compatible.

Vérifiez :

1. quel appareil ou quelle clock est éligible pour piloter le domaine de timing AES67 ;
2. la version PTP et le numéro de domaine utilisés par chaque terminal participant ;
3. si les appareils Dante utilisent une configuration de clock AES67 automatique ou manuelle ;
4. si un appareil fait le pont avec le comportement de timing requis entre les côtés natif et AES67 ;
5. le DSCP et le traitement des messages PTP event et general par les switches ;
6. l’effet de la perte du leader, d’un uplink ou d’un terminal.

Ne supposez pas que des appareils visibles partagent une clock exploitable. La découverte, le contrôle et le timing des médias sont des vérifications distinctes. Le guide du leader de clock Dante explique l’élection native Dante ; la frontière AES67 doit malgré tout faire l’objet de sa propre vérification PTPv2.

Garder le multicast dans un périmètre réseau intentionnel

Un flux AES67 n’est pas une raison d’inonder tous les ports. Cartographiez le VLAN et le chemin des switches, puis configurez les contrôles multicast pour cette conception.

Un réseau managé peut utiliser l’IGMP snooping pour envoyer le flux uniquement vers les ports ayant des récepteurs intéressés, avec un querier correctement placé qui maintient l’appartenance. La politique exacte relève du propriétaire du réseau. Vérifiez que PTPv2, la découverte lorsqu’elle est requise, et le RTP multicast atteignent bien les terminaux visés sans fuite vers d’autres réseaux de production.

Vérifiez aussi la capacité des liens dans les deux sens. Le multicast réduit le fanout de l’émetteur, mais chaque flux consomme toujours de la bande passante sur chaque lien qui le transporte. Le guide des exigences de switch réseau Dante couvre le débit de lien, la QoS, l’EEE, les compteurs et les tests d’acceptation.

Tester l’interopérabilité depuis le silence jusqu’à la récupération

1. Sauvegarder la base native connue

Exportez la configuration Dante actuelle et relevez l’horloge, les routes, les fréquences d’échantillonnage, les noms, les adresses et l’état des switches. Protégez les sorties opérationnelles avant d’activer un nouveau mode RTP.

2. Configurer une frontière à la fois

N’activez le mode requis que sur les terminaux pris en charge. Appliquez le format, le préfixe multicast, la latence et les paramètres PTPv2 convenus. Laissez tout redémarrage nécessaire se terminer avant de juger le résultat.

3. Créer un flux de test unique et identifiable

Commencez par un petit ensemble de canaux et une source de test sans ambiguïté. Notez l’ordre des canaux, l’adresse multicast, le port et l’émetteur. Évitez de créer plusieurs flux anonymes en même temps.

4. S’abonner et inspecter chaque couche

Confirmez que le récepteur rejoint le flux prévu, se verrouille sur la bonne clock, ne signale aucune erreur et produit l’audio correct sur la sortie attendue. Une indication de routage seule ne prouve pas la présence d’un média audible et correctement identifié.

5. Appliquer une charge réaliste

Faites fonctionner ensemble les routes Dante natives prévues, les flux AES67 et un trafic partagé représentatif. Surveillez l’état de clock, la latence, les erreurs de paquets, l’utilisation des liens, les files d’attente et les destinations réelles.

6. Exercer la panne et le retour arrière

Retirez puis rétablissez, un par un, la source, le récepteur, le leader de clock et le lien réseau concerné. Mesurez le comportement de coupure et de reprise. Enfin, prouvez que la base documentée peut être restaurée sans inventer de réglages.

Documenter la frontière d’interopérabilité

La fiche technique devrait inclure :

• la raison opérationnelle d’utiliser AES67 ;
• les terminaux Dante natifs et AES67 par appareil, port et canal ;
• le firmware et le responsable de la compatibilité ;
• le format audio et l’ordre des canaux ;
• l’adresse RTP multicast, le port et la plage autorisée ;
• le leader PTPv2, le domaine, les priorités et le fallback ;
• le VLAN, les switches, le propriétaire IGMP, la QoS et la capacité de lien ;
• la latence du récepteur et les preuves d’acceptation ;
• les procédures de redémarrage, de panne, de spare et de rollback ;
• le technicien autorisé à modifier chaque côté.

Ne placez pas de mots de passe ni d’identifiants réseau sensibles dans une fiche technique publique. Partagez-les via le canal sécurisé approuvé par la salle.

Le guide de fiche technique réseau audio numérique montre comment placer cette frontière à côté du reste de la remise du show.

Checklist Dante et AES67

• AES67 est requis par une frontière d’interopérabilité non-Dante nommée.
• Chaque terminal et chaque version de firmware prennent en charge le mode sélectionné.
• La fréquence d’échantillonnage, l’encodage, l’ordre des canaux, l’adresse multicast et le port correspondent.
• La source PTPv2, le domaine, la priorité et le fallback sont vérifiés.
• Le périmètre multicast, le querier, la QoS, l’EEE et la capacité de lien sont approuvés.
• La route passe les tests de bon audio, de charge complète, de panne et de récupération.
• Les routes Dante natives restent documentées et récupérables.
• Le propriétaire et la procédure de rollback figurent dans la fiche technique.

Erreurs fréquentes

Traiter AES67 comme un système de contrôle complet. Il standardise un chemin média interopérable, pas tous les comportements de découverte, de routage, de sécurité ou de supervision.

Activer AES67 sur chaque appareil Dante. N’activez et ne configurez cette fonction que là où une frontière non-Dante approuvée l’exige.

Vérifier la route sans vérifier la clock. Un récepteur peut découvrir un flux mais ne pas produire un audio stable sans timing PTPv2 compatible.

Copier les valeurs multicast à l’aveugle. Les plages d’adresses, les préfixes, les ports et la prise en charge des appareils doivent correspondre aux terminaux réels et au plan réseau.

Tester un seul flux sur un switch inactif. L’acceptation doit inclure les routes natives, la charge AES67 prévue, le trafic partagé, les pannes et la récupération.

FAQ

Quelle est la différence entre Dante et AES67 ?

Dante est une plateforme média en réseau complète avec routage, découverte, clocking, supervision et configuration des appareils. AES67 est une norme qui permet à des systèmes audio-over-IP compatibles d’échanger des flux audio RTP.

Dante est-il compatible avec AES67 ?

Les appareils Dante pris en charge peuvent envoyer et recevoir de l’audio AES67 vers et depuis des appareils AES67 non-Dante compatibles. La compatibilité dépend de l’appareil, du firmware, du format audio, des paramètres multicast et de la configuration PTPv2.

AES67 utilise-t-il le multicast ?

L’interopérabilité AES67 utilise couramment des flux RTP multicast. L’émetteur, le récepteur, les switches, le VLAN, l’adresse multicast, le port et la politique IGMP doivent tous s’intégrer dans le même plan.

AES67 nécessite-t-il PTPv2 ?

Oui. AES67 utilise PTPv2 pour la synchronisation de l’horloge média. Les terminaux participants doivent partager une configuration PTPv2 et un chemin de timing compatibles.

Comment tester l’interopérabilité Dante et AES67 ?

Vérifiez les capacités et les formats, configurez PTPv2, créez un flux RTP multicast connu, confirmez l’audio correct à la destination, puis testez la charge complète, la perte de clock et de liens, le retour des terminaux et le rollback.

Garder la frontière de normes récupérable

Conservez la cartographie approuvée des terminaux, le flux RTP, le plan de clock, le périmètre réseau, les preuves de test et le rollback à côté du reste de la documentation du show. Dans Techrider.live, gardez-les avec la même fiche technique que le plan de scène et la liste d’entrées, invitez l’ingénieur responsable à la modifier, puis enregistrez et vérifiez l’historique avant de partager la version courante.