Dante et AES67

Norme ouverte face à écosystème commercial

L'AES67 est maintenue comme une norme publique. Son but est de définir une surface d'interopérabilité commune que de nombreux fabricants peuvent implémenter sans adopter le contrôleur, le modèle de découverte ou la famille de produits d'une seule société. Dante est un écosystème technologique commercial détenu et développé par Audinate. Il offre une expérience utilisateur complète couvrant la découverte, le routage, l'horloge, la gestion des appareils, les cartes son virtuelles, les logiciels et le matériel certifié.

Cette différence n'est pas un défaut de l'un ou l'autre modèle. Un organisme de normalisation peut définir une couche commune durable, mais ne peut pas garantir l'expérience utilisateur de chaque implémentation. Un écosystème commercial peut livrer des outils étroitement intégrés et un comportement prévisible, mais il reste sous le contrôle de son propriétaire.

L'interopérabilité Dante AES67 se comprend donc mieux comme un point de rencontre entre ces modèles. Les appareils Dante peuvent exposer certains flux sous une forme compatible AES67, et les appareils AES67 peuvent recevoir ou émettre ces flux. Le reste du flux de travail Dante reste spécifique à Dante.

Propriété et contexte de marque

L'AES67 est développé à travers les travaux de normalisation de l'AES. Dante ainsi que les noms, logos et spécifications techniques associés sont contrôlés par Audinate. Un produit qui prend en charge l'interopérabilité Dante AES67 n'est pas open source pour autant, et une implémentation AES67 ne devient pas par définition un produit Dante.

L'exactitude des marques compte dans la rédaction technique. Utilisez Dante uniquement pour décrire la technologie d'Audinate et employez les noms officiels du fabricant pour désigner un appareil ou un mode précis. Évitez de laisser croire que l'AES67 possède Dante ou que Dante est un synonyme générique d'AoIP.

Dante est une marque d'Audinate Pty Ltd. Cette page est une comparaison technique indépendante.

L'attribution des marques est un contexte éditorial, pas un substitut à la lecture des conditions actuelles du fournisseur.

Découverte, routage et contrôle

Les appareils Dante natifs se découvrent généralement via l'écosystème de contrôle Dante et se gèrent avec des outils comme Dante Controller ou Dante Director, selon le produit et le déploiement. L'utilisateur voit noms d'appareils, libellés de canaux, abonnements, état d'horloge et diagnostics dans une interface unifiée.

L'AES67 ne définit pas un protocole universel de découverte ou de routage. Quand Dante opère en mode d'interopérabilité AES67, le flux audio peut être visible d'un système externe via une description de session ou un mécanisme de découverte compatible, mais cela ne signifie pas que chaque fonction Dante devient disponible dans le contrôleur externe.

Les intégrateurs doivent documenter deux couches : les flux audio qui franchissent la frontière AES67 et les actions de gestion qui restent natives. Un schéma hybride utile montre Dante Controller d'un côté, l'appareil ou le contrôleur AES67 de l'autre, et les points exacts où SDP, adresses de multidiffusion, configuration PTP et mappage des canaux sont échangés.

Horloge, latence et redondance

Dante utilise son propre modèle d'horloge et offre des réglages de latence configurables pour les flux natifs. Le mode AES67 peut imposer une durée de paquet ou un réglage de latence différent, car le contrat d'interopérabilité doit correspondre à l'appareil externe. Une conception réussie doit utiliser la même fréquence d'échantillonnage, la même durée de paquet et la même relation d'horloge des deux côtés de la connexion.

La latence n'est pas un chiffre unique. Elle comprend la paquetisation, la mise en tampon du récepteur, le traitement de l'appareil, le transit réseau et toute conversion entre modes natif et interopérabilité. La comparaison la plus sûre est la latence de bout en bout mesurée dans la topologie réelle, pas le réglage le plus bas imprimé sur une fiche technique.

Dante fournit des options de redondance au sein de son écosystème, tandis que l'AES67 elle-même ne définit pas de mécanisme universel de protection sans interruption. Un déploiement hybride peut préserver la redondance native dans le domaine Dante tout en exposant un modèle de protection différent à la frontière AES67. Le comportement en panne de cette frontière doit être testé et documenté.

L'alignement PTP est tout aussi important. Les appareils Dante et les appareils AES67 peuvent devoir partager une référence d'horloge ou relier deux domaines de temporisation de manière contrôlée. Une planification PTP médiocre peut produire un audio intermittent même quand le routage et la bande passante semblent corrects.

Gestion et support

La gestion Dante native couvre plus que l'abonnement audio : nommage des appareils, libellés de canaux, supervision d'horloge, processus de mise à jour du firmware, journaux d'événements et accès aux services ou logiciels d'Audinate. Le mode d'interopérabilité AES67 n'expose pas automatiquement ces fonctions de gestion à un système tiers.

Un projet hybride doit définir qui possède chaque couche. Qui attribue les noms d'appareils Dante ? Qui gère les adresses de multidiffusion AES67 ? Qui supervise le PTP ? Qui reçoit les alarmes si un flux disparaît ? Qui met à jour le firmware de chaque côté de la frontière ? Une propriété ambiguë est une cause fréquente de résolution lente des incidents.

Les frontières de support doivent être explicites elles aussi. Un fournisseur peut prendre en charge l'appareil Dante, le mode AES67 et la configuration réseau séparément, tout en refusant la responsabilité d'un contrôleur tiers ou d'une conception de commutateur non standard. Une matrice d'intégration écrite réduit les renvois de responsabilité pendant la mise en service et l'exploitation.

Certification et déclarations de conformité

Les produits Dante participent au programme de produits et de certification d'Audinate, et l'ensemble des fonctions disponibles varie selon la classe d'appareil, le matériel, le firmware et la licence. La prise en charge AES67 doit être vérifiée pour le modèle exact et la version de firmware, pas déduite de la marque Dante.

Une revue de conformité utile pose quatre questions. L'appareil prend-il en charge la direction de flux AES67 requise ? Prend-il en charge la fréquence d'échantillonnage et la durée de paquet ? Expose-t-il le nombre de canaux nécessaire ? Son comportement d'horloge et de redondance convient-il à la conception du système ? Une cinquième question : le fabricant documente-t-il les limites du mode d'interopérabilité ?

La certification est une preuve concernant une configuration testée précise, pas la preuve que toutes les combinaisons se comporteront de manière identique. Conservez la version de firmware, l'export de configuration, les scripts de test et les résultats mesurés dans le dossier du projet.

Ce que change le mode Dante AES67

Dans un déploiement Dante AES67 typique, certains flux d'émission ou de réception sont configurés pour utiliser un transport et une relation de temporisation compatibles AES67. Cela peut permettre à un réseau Dante d'alimenter un processeur non-Dante, un appareil broadcast, un système d'enregistrement ou une autre plateforme AoIP qui prend en charge le même profil d'interopérabilité.

La frontière est généralement plus étroite que le flux de travail natif. Un récepteur AES67 ne connaît pas nécessairement le nom de l'appareil Dante, les libellés de canaux ou le modèle d'abonnement. Il peut ne voir qu'un flux IP décrit par SDP. Inversement, le contrôleur Dante peut ne pas pouvoir gérer chaque propriété du récepteur externe.

Certaines fonctions peuvent aussi changer quand un appareil quitte le mode Dante natif. Les nombres de canaux peuvent être réduits, les réglages de latence limités, les fréquences d'échantillonnage contraintes et le comportement de redondance différent. Ces limites sont propres à chaque implémentation et doivent être confirmées dans la documentation produit actuelle.

Limites à anticiper

La plus grande limite n'est pas toujours la bande passante : c'est la visibilité opérationnelle. Un opérateur Dante peut voir un réseau natif sain alors qu'une interconnexion AES67 est tombée, ou un contrôleur AES67 peut afficher un flux sans savoir que sa source Dante est entrée dans un état natif dégradé. La supervision inter-domaines est essentielle.

La conception de la multidiffusion est un autre risque courant. Dante, l'AES67 et le réseau environnant peuvent suivre des conventions différentes d'allocation d'adresses, de comportement IGMP et de densité de flux. Un plan de multidiffusion propre doit réserver des plages, limiter l'appartenance aux groupes et vérifier le comportement du querier sur chaque VLAN.

Enfin, une connexion Dante AES67 n'est pas un convertisseur universel pour tous les formats ou fonctions de contrôle. Elle ne transforme pas les signaux non audio en audio, ne remplace pas un convertisseur de fréquence d'échantillonnage et ne garantit pas qu'un appareil tiers puisse contrôler un produit Dante. Ces fonctions exigent des produits distincts ou une intégration de gestion.

Déploiements Dante pur et hybrides

Un déploiement Dante pur est généralement l'option la plus simple lorsque chaque point de terminaison critique vient de l'écosystème Dante et que le projet valorise un contrôleur unique, un modèle de support unique et des fonctions natives prévisibles. Ajouter l'AES67 à un système Dante sain peut introduire une charge d'horloge, de multidiffusion et de test dont le projet n'a pas besoin.

Un déploiement hybride se justifie lorsqu'une installation doit relier un parc Dante à un système RAVENNA, à un cœur de production ST 2110-30, à un processeur tiers ou à une plateforme d'enregistrement ou de supervision fondée sur des normes. Il se justifie aussi pendant une migration, quand un site veut introduire un nouveau sous-système sans remplacer le réseau Dante existant.

La question de conception pratique n'est pas « pur contre hybride » dans l'absolu, mais : quels flux doivent franchir la frontière et quelle garantie chaque flux exige-t-il ? Un petit nombre de flux de surveillance à faible risque peut tolérer un pont simple. Un chemin de direct broadcast peut exiger des réseaux redondants, une temporisation déterministe, de la supervision et une procédure de panne testée.

Liste de vérification et idées reçues

Commencez la liste par les exigences des flux : direction, fréquence d'échantillonnage, durée de paquet, nombre de canaux, multidiffusion ou monodiffusion, comportement de reprise attendu. Vérifiez ensuite le modèle Dante, le firmware, la licence, le mode d'interopérabilité, la configuration PTP, la prise en charge de redondance et la visibilité de gestion. Testez la paire d'appareils exacte, pas seulement la catégorie marketing.

Une idée reçue courante : la prise en charge AES67 rendrait un appareil Dante générique. En pratique, le comportement Dante natif reste le cœur de l'expérience produit. Une autre idée reçue : le mode AES67 serait toujours gratuit ou toujours identique d'un modèle à l'autre. Licences, matériel, firmware et gamme de produit peuvent tous influencer la disponibilité.

Une troisième idée reçue consiste à voir l'interopérabilité comme un simple détail d'ingénierie. Elle change les achats, l'exploitation, le support et la formation. La meilleure conception hybride donne à chaque écosystème un rôle clair et crée une frontière étroite, documentée, avec des critères d'acceptation mesurables.

• Confirmez le modèle Dante exact et la version de firmware.
• Vérifiez la direction AES67, le nombre de canaux et le format de paquets.
• Documentez la frontière PTP et d'horloge.
• Décidez comment multidiffusion, redondance et supervision fonctionneront.
• Testez la reprise avant la mise en service du système.