Qu'est-ce que l'AES67 ?

Définition et contexte des révisions

L'AES67 porte officiellement le titre de norme AES pour les applications audio des réseaux : interopérabilité de l'audio en flux à haute performance sur IP (High-performance streaming audio-over-IP interoperability). L'Audio Engineering Society a publié la première édition en 2013, puis la révision AES67-2018 après que l'expérience de terrain a mis en évidence des ambiguïtés et des détails d'intégration nécessitant un traitement plus clair.

La norme ne crée pas un écosystème fermé unique. Elle définit un point de rencontre technique où des produits de fabricants différents peuvent échanger de l'audio en temps réel lorsque chaque produit implémente le profil requis et que l'intégrateur système configure correctement le réseau partagé. La conformité est donc un point de départ, pas une promesse que chaque fonction optionnelle ou chaque fonction de gestion fonctionnera automatiquement.

Pour les travaux d'achat et de conception, citez l'édition utilisée et vérifiez la déclaration de conformité du fabricant. AES67-2018 est la révision que référencent la plupart des documents d'achat actuels, mais les équipes doivent tout de même consulter le catalogue des normes de l'AES pour vérifier les amendements, corrigenda ou éditions ultérieures avant de figer une spécification.

La norme définit l'interopérabilité à certaines couches. Elle ne normalise pas chaque comportement opérationnel que voit l'utilisateur.

Le problème d'interopérabilité que l'AES67 résout

Avant l'AES67, chaque plateforme d'audio sur IP résolvait des problèmes similaires à sa manière. Un réseau Dante, un réseau RAVENNA, un système Livewire ou une installation Q-LAN pouvait offrir un excellent audio en temps réel au sein de sa propre famille de produits, mais le routage direct entre fabricants exigeait souvent des passerelles, du matériel de conversion ou des solutions de contournement manuelles.

Cette fragmentation créait un risque commercial et opérationnel. Une installation pouvait devenir dépendante d'un seul écosystème pour le routage, l'horloge, le contrôle et le support. Étendre le système imposait de vérifier la compatibilité des protocoles avant même d'évaluer l'acoustique, le flux de travail ou le prix. Les équipements existants devenaient plus difficiles à conserver à l'arrivée d'une nouvelle plateforme.

L'AES67 répond à ce problème en spécifiant un chemin d'interopérabilité commun pour le transport audio. Elle permet à un écosystème natif d'exposer certains flux sous une forme qu'un autre écosystème compatible AES67 peut recevoir. C'est pourquoi l'AES67 est souvent décrite comme un pont : elle n'efface pas les différences entre plateformes, mais elle rend possible un déplacement contrôlé entre elles.

Les fondamentaux de l'audio sur IP

Un système AoIP convertit l'audio échantillonné en paquets horodatés, envoie ces paquets sur une infrastructure Ethernet et IP, puis reconstruit un signal audio continu côté récepteur. La difficulté ne consiste pas à déplacer des octets : elle consiste à préserver le minutage des échantillons, la relation entre canaux et la continuité de lecture tout en partageant un réseau en mode paquets avec d'autres trafics.

L'AES67 suppose un réseau administré capable de séparer les médias en temps réel des données ordinaires. Les commutateurs réseau doivent disposer d'une mémoire tampon suffisante, du contrôle de la multidiffusion et de la priorisation du trafic. Les routeurs peuvent transporter des flux entre sous-réseaux lorsque la conception prend en charge le routage de multidiffusion ou des flux en monodiffusion, mais chaque frontière ajoute des exigences de configuration et de supervision.

L'horloge média est distincte de l'horloge des paquets. Le PTP aligne l'heure des appareils, tandis que la fréquence d'échantillonnage audio définit l'horloge média. Un récepteur doit reconstituer à la fois la phase d'échantillonnage correcte et un flux stable d'échantillons. La perte de paquets, une gigue excessive ou une horloge instable peuvent provoquer des coupures même lorsque la bande passante moyenne du réseau est largement suffisante.

Traitez la conception réseau comme une partie du système audio, et non comme une infrastructure secondaire. Les VLAN, la QoS, les domaines PTP, les requéreurs (queriers) de multidiffusion et les politiques de mémoire tampon des commutateurs doivent être validés ensemble. Pour les chemins de programme critiques, il faut aussi définir le mode dégradé, le cheminement des alarmes et le temps de rétablissement après une panne.

• L'échantillonnage convertit l'audio analogique en valeurs numériques discrètes à une cadence définie.
• La paquetisation ajoute les informations de séquence, d'horodatage et de charge utile pour que les récepteurs puissent reconstruire le flux.
• La mise en tampon absorbe les variations normales du réseau, mais augmente la latence de bout en bout.
• La synchronisation d'horloge maintient des appareils indépendants alignés sur une même référence de temps partagée.

PTPv2, RTP et SDP

L'AES67 utilise le protocole IEEE 1588-2008 Precision Time Protocol, communément appelé PTPv2, pour distribuer une référence de temps commune. Les messages PTP permettent aux appareils de comparer leurs horodatages et de corriger le retard réseau. Dans les systèmes audio, la base de temps obtenue permet aux émetteurs et aux récepteurs de placer les échantillons sur une chronologie partagée plutôt que de dépendre uniquement de la fréquence de l'oscillateur local.

Le protocole Real-time Transport Protocol, défini dans la RFC 3550, transporte la charge utile audio. Le RTP fournit des numéros de séquence et des horodatages qui permettent aux récepteurs de détecter les paquets manquants ou réordonnés et de reconstituer l'instant de lecture voulu. Le RTP Control Protocol peut fournir des statistiques de réception, même si les choix de contrôle et de supervision varient selon les produits.

Le protocole Session Description Protocol décrit le flux avant sa réception. Un document SDP identifie le type de média, l'adresse, le port, le format de charge utile, la durée de paquet, le mappage des canaux et d'autres paramètres. Dans certains systèmes, le SDP est échangé directement ; dans d'autres, il est porté par une couche de découverte ou de gestion. Parce que l'AES67 ne définit pas un protocole universel de contrôle des appareils, la gestion du SDP peut différer d'une implémentation à l'autre.

PTP, RTP et SDP sont des normes utilisées par l'AES67. Ce ne sont pas des mentions marketing optionnelles.

QoS, PCM et comportement en multidiffusion

L'AES67 utilise l'audio PCM linéaire afin que les récepteurs n'aient pas besoin d'un codec propriétaire pour interopérer. Les formes de charge utile courantes sont le PCM 16 bits et 24 bits, souvent désignées par des types de charge utile RTP tels que L16 et L24. Un émetteur et un récepteur doivent s'accorder sur la fréquence d'échantillonnage, la durée de paquet, le type de charge utile, le nombre de canaux et l'ordre des canaux.

La qualité de service compte parce que les paquets audio sont sensibles au retard sans nécessairement consommer beaucoup de bande passante. Les marquages DSCP et le traitement des files donnent la priorité au trafic PTP et RTP sur les transferts de fichiers, les sauvegardes et les données bureautiques générales. Un VLAN peut aider à séparer le trafic média, mais la séparation par VLAN ne remplace pas à elle seule une conception et une supervision correctes des files d'attente.

La multidiffusion permet à un émetteur de distribuer un flux à plusieurs récepteurs sans dupliquer le trafic pour chaque destination. Elle introduit aussi des risques : un IGMP snooping mal configuré, l'absence de requéreur ou une diffusion accidentelle peuvent perturber tout le réseau. Les grands déploiements doivent planifier les plages d'adresses de multidiffusion, l'emplacement des requéreurs, les limites de groupes et les domaines PTP avant la mise en service.

Après la mise en production, la perte de paquets, la gigue, le décalage PTP, l'état IGMP et les files des commutateurs doivent être observés en continu. De nombreux problèmes d'interopérabilité ne se manifestent pas par un silence complet, mais par des coupures intermittentes, des canaux gauche et droite inversés, une incapacité à repartir après un redémarrage ou des anomalies qui n'apparaissent qu'en charge plus élevée. L'observabilité doit être conçue en même temps que le chemin audio.

• Réservez de la capacité et des budgets de files d'attente pour le trafic média.
• Utilisez un plan d'adresses de multidiffusion documenté.
• Vérifiez les paramètres de domaine et de priorité PTP sur tous les commutateurs.
• Surveillez la perte de paquets, la gigue, les décalages d'horloge et l'état IGMP après le déploiement.

Ce que l'AES67 ne définit pas

L'AES67 n'impose pas un système unique de découverte automatique des appareils. Certains produits utilisent des annonces SAP, d'autres mDNS ou Bonjour, d'autres s'appuient sur un contrôleur natif ou sur un outil d'orchestration tiers. Un appareil peut être compatible AES67 et exiger néanmoins un échange manuel de SDP ou un logiciel du fabricant pour établir une connexion.

Elle ne définit pas non plus un modèle universel de gestion des connexions, une interface utilisateur obligatoire ni une architecture de sécurité complète. Les droits de routage, les conventions de nommage, les mises à jour du firmware, le contrôle d'accès et les API de supervision restent propres à chaque produit. C'est une raison pour laquelle l'interopérabilité AES67 fonctionne souvent mieux lorsqu'un contrôleur ou une couche de gestion placée au-dessus du transport audio peut coordonner les points de terminaison.

La redondance est une autre frontière importante. L'AES67 définit les couches de diffusion et de synchronisation, pas la duplication transparente des paquets ni la bascule. Les systèmes qui exigent une redondance sans interruption ajoutent généralement un schéma de redondance réseau issu de l'architecture environnante, par exemple des liaisons doublées avec une méthode de protection propre aux médias, et le comportement exact dépend des produits et de la conception réseau.

Enfin, l'AES67 ne garantit pas l'interopérabilité au simple motif qu'un logo figure sur une fiche technique. L'implémentation doit encore négocier des paramètres compatibles, prendre en charge le format de charge utile requis et se comporter correctement dans les conditions PTP et réseau attendues.

Interopérabilité entre Dante, RAVENNA et AES67

Dante est la technologie propriétaire de mise en réseau audio d'Audinate. L'interopérabilité AES67 de Dante se présente généralement sous la forme d'un mode ou d'une configuration qui permet à certains flux Dante d'échanger de l'audio avec d'autres appareils AES67. La découverte, le routage, le contrôle et la gestion Dante natifs restent partie de l'écosystème Dante, si bien qu'une connexion AES67 peut coexister avec un plan de contrôle qui exige toujours Dante Controller ou un autre outil Audinate.

RAVENNA est une plateforme technologique ouverte construite autour de protocoles IP standard et fortement alignée sur l'AES67 et le SMPTE ST 2110-30. Elle peut porter des profils, des formats, des nombres de canaux, des options de synchronisation et des modèles de redondance supplémentaires au-delà du contrat minimal d'interopérabilité AES67. L'AES67 est donc une couche commune au sein d'un déploiement RAVENNA plus large, et non une description complète de chaque capacité RAVENNA.

Les conceptions hybrides sont courantes. Une installation peut conserver un parc Dante natif pour les boîtiers de scène, les amplificateurs et les consoles, tout en utilisant l'AES67 pour relier un cœur broadcast, un système de production RAVENNA ou un processeur tiers précis. Le plan d'intégration doit identifier quels points de terminaison sont natifs, lesquels sont en mode d'interopérabilité, où le SDP est échangé et qui possède la politique d'horloge et de multidiffusion.

La partie la plus fragile n'est souvent pas de savoir si l'audio peut être envoyé, mais comment la frontière est maintenue. Il faut définir tôt dans le projet si les deux côtés se reconnectent après une mise à jour du firmware, un redémarrage d'appareil, une bascule de grandmaster ou une panne réseau ; si les alarmes arrivent en un point unique ; et s'il existe une procédure de maintenance claire.

Le mode d'interopérabilité est un choix de conception système. Il n'efface pas les différences de fonctions natives.

Recommandations de déploiement

Commencez par un plan écrit des signaux et des horloges. Listez chaque flux, sa direction, sa fréquence d'échantillonnage, sa durée de paquet, son nombre de canaux, son groupe de multidiffusion, son adresse source, son récepteur et son chemin de repli. Décidez si le réseau utilisera la monodiffusion ou la multidiffusion pour chaque classe de trafic, et définissez comment le SDP sera transmis et conservé.

Construisez un plan de domaine PTP avant d'ajouter des points de terminaison. Confirmez quels appareils peuvent être grandmasters, comment les horloges frontières (boundary clocks) ou transparentes sont traitées, ce qui se passe si le grandmaster préféré disparaît et si le réseau dispose d'une stratégie de maintien (holdover) stable. Testez les performances PTP avec la même configuration de commutateurs et la même charge de trafic que celles prévues en exploitation.

Testez ensuite l'interopérabilité comme un système, pas comme une démonstration de produit. Vérifiez le mappage des canaux, le gain nominal, l'alignement des échantillons, la reprise des flux après un événement de liaison, le comportement d'adhésion et de départ en multidiffusion et la visibilité de gestion. Incluez les cas limites : firmware incompatible, grandmaster redémarré, récepteur débranché, liaison montante congestionnée.

La mise en service doit laisser des preuves durables : configurations des commutateurs, journaux PTP, relevés de flux, résultats de tests et responsabilités des évolutions futures. L'AES67 simplifie le contrat de transport, mais elle ne supprime pas l'exigence de rigueur réseau professionnelle.

Les solutions modules AES67 SoundNet

Comprendre la norme est une chose ; faire en sorte qu'un produit parle AES67 de manière fiable en est une autre. Les modules OEM de la série YW de SoundNet rassemblent une implémentation AES67 complète et éprouvée en production — horloge PTPv2, transport audio RTP et découverte des équipements — dans du matériel intégrable. Les fabricants audio professionnels peuvent ainsi ajouter l'audio réseau à leurs produits sans développer la pile protocolaire de zéro. La gamme va du compact YW04d 4×4 au module Mini-PCI YWRG128 offrant jusqu'à 128×128 canaux à 48, 96 ou 192 kHz.

Autour des modules s'ajoute une chaîne d'outils couvrant tout le flux de travail : l'AES67 LINK Controller sans licence pour le routage et la configuration, la AES67 Virtual Soundcard qui transforme un PC en point de terminaison 64×64, l'AES67 Panel alimenté en PoE pour le contrôle de salle, et le Stream Monitor open source pour vérifier les flux multicast sur un réseau en service.

• Pile AES67 complète embarquée : synchronisation, transport et découverte sont gérés par le module, pas par votre équipe firmware
• De 4×4 à 128×128 canaux via des interfaces I2S/TDM à 48/96/192 kHz
• DSP embarqué en option : EQ paramétrique, filtres, délai, noise gate et anti-larsen
• Un seul effort d'intégration pour toute la famille, du petit endpoint au transport haute densité
• Outils prêts pour le produit fini : LINK Controller, VSC, Panel et Stream Monitor couvrent configuration, routage et supervision

Applications et idées reçues

L'AES67 est utilisée dans les installations broadcast, les lieux de culte, les centres de conférence, les stades, les salles de spectacle, les studios d'enregistrement et les grands campus. Elle est particulièrement utile lorsque des équipements de plusieurs fabricants doivent partager l'audio, lorsqu'un parc AoIP existant doit être relié à un nouveau cœur de production, ou lorsqu'un transport fondé sur des normes est exigé pour la maintenabilité à long terme.

Une première idée reçue consiste à croire que l'AES67 signifie que tout appareil AES67 se pilote de la même façon. En pratique, l'audio peut circuler tandis que la découverte, le routage, les libellés et la supervision restent séparés. Une autre idée reçue est de voir dans l'AES67 un niveau de qualité ou un codec. C'est un cadre d'interopérabilité ; la qualité audio dépend de la source, du format d'échantillonnage, de l'horloge et du comportement du réseau.

Une troisième idée reçue : AES67 et ST 2110-30 seraient deux noms interchangeables pour une même norme. Elles sont étroitement liées, mais l'AES67 est une norme AES d'interopérabilité audio, tandis que ST 2110-30 est un composant audio contraint de la suite SMPTE plus large des médias professionnels sur IP. Certains documents techniques écrivent ST2110 sans espace pour désigner la famille. La distinction compte lorsqu'on spécifie des flux de travail broadcast, le contrôle NMOS, les profils PTP et les niveaux de conformité.

Enfin, l'AES67 n'est pas un bouton qui résout automatiquement toute question de compatibilité. L'étendue de la prise en charge par les produits, les options disponibles, les licences, l'état du firmware, la conception réseau et les procédures opérationnelles influencent toutes le résultat. Écrire clairement les limites et exécuter des tests d'acceptation de bout en bout est plus fiable que de se fier aux logos ou aux arguments commerciaux.