Comprendre AES67 et son rôle dans la radiodiffusion moderne

L'industrie de la radiodiffusion subit un changement fondamental vers une infrastructure basée sur la propriété intellectuelle, qui doit être plus souple, plus évolutive et plus rentable. À mesure que la production à distance et les flux de travail audio basés sur le cloud passent de l'expérimentation à l'usage courant, un défi commun se pose : comment assurer une interopérabilité sans faille entre les divers équipements audio-over-IP (AoIP), les codecs et les plates-formes logicielles en usage aujourd'hui.

AES67 est une norme d'interopérabilité audio-over-IP développée par l'Audio Engineering Society. Publiée sous la cote AES67-2018, elle fournit une couche de transport commune qui permet aux appareils de différents fabricants, chacun avec ses propres écosystèmes AoIP propriétaires (comme Dante, Ravenna ou Q-LAN), d'échanger des flux audio de haute qualité sur des réseaux IP standard. En définissant les paramètres requis pour l'horlogerie, la synchronisation, le format de flux et le transport des médias, AES67 élimine les obstacles qui, une fois que les diffuseurs ont forcé des solutions à un seul fournisseur.

La norme a acquis une large adoption parce qu'elle s'adresse à un point de douleur familier à tout ingénieur qui a essayé de connecter une console de mixage équipée de Dante à un codec basé sur RAVENNA. Avant AES67, une telle connexion nécessite un matériel de transition coûteux ou des passerelles propriétaires. Maintenant, avec une configuration appropriée, les appareils d'Auvinate, Layo, Merging Technologies, et d'autres peuvent passer directement l'audio.

Composantes techniques de base de l'AES67

Pour réussir la mise en œuvre de l'AES67, les ingénieurs doivent comprendre ses piliers techniques clés. La norme précise l'utilisation de RTP (Real-time Transport Protocol) pour la livraison de charge utile audio, transportant généralement jusqu'à 8 canaux de 24 bits, 48 kHz audio par flux. La synchronisation repose sur le protocole IEEE 1588 Precision Time Protocol (PTP), en utilisant un profil dérivé de SMPTE ST 2059.

AES67 charge également des paramètres spécifiques de qualité de service (QoS) de prioriser le trafic audio sur les réseaux encombrés, notamment l'utilisation de points de code DiffServ (DSCP) pour marquer les paquets, avec des valeurs recommandées pour l'audio (généralement EF ou AF41) et contrôler le trafic. La norme définit des limites de latence acceptables aussi peu que 1 milliseconde pour les réseaux locaux, ce qui le rend adapté pour la production en direct où le retard doit être imperceptible.

Le format de charge utile RTP pour AES67 utilise le schéma de codage audio L24, qui intègre des échantillons PCM linéaires dans des conteneurs 24 bits. Chaque paquet RTP porte un nombre fixe d'échantillons par canal, avec le temps de paquet généralement fixé à 1 milliseconde pour les applications à faible latence. La norme spécifie également comment gérer les flux redondants et la perte de paquets dissimulation, bien que ces mécanismes soient optionnels et dépendants de l'implémentation.

Comparaison avec d'autres normes AoIP

Bien que l'AES67 soit une couche d'interopérabilité, elle est souvent confondue avec des écosystèmes à caractéristiques multiples comme Dante ou Ravenna. Dante (Audinate) est une plateforme de réseautage complète avec ses propres logiciels de gestion, ses capacités de découverte automatique et de routage ; son récent mode AES67 permet aux appareils de fonctionner comme des terminaux AES67. Ravenna, développé par Layo et ALC NetX, est une autre solution audio IP qui supporte nativement AES67 et RAVENNA-Generated PTP. ST 2110-30 (Audio, PCM non compressé) étend ces concepts pour les flux de travail vidéo de radiodiffusion, en utilisant AES67 comme son transport audio.

Une distinction essentielle est que AES67 ne fournit pas de découverte de périphérique, de gestion de connexion, ou de contrôle de routage. Il est uniquement un standard de transport et de synchronisation. Pour l'automatisation complète du flux de travail, les radiodiffuseurs associent généralement AES67 avec NMOS (Networked Media Open Specifications) IS-04 et IS-05, qui fournissent une gestion de découverte et de connexion basée sur le registre.

Mise en œuvre de l'AES67 dans la production à distance

La production à distance, que ce soit pour des activités sportives, des nouvelles ou en direct, exige un transport audio fiable et à faible latence sur des distances pouvant s'étendre sur des centaines ou des milliers de kilomètres. AES67 offre une façon normalisée de transporter les flux de microphone, les signaux interphones et les programmes audio sur des circuits IP dédiés ou des WAN privés, souvent en conjonction avec des vidéos envoyées via ST 2110 ou des codecs compressés (p. ex. JPEG XS).

Mise en œuvre étape par étape pour les sites éloignés

Les étapes suivantes offrent un guide pratique pour intégrer AES67 dans un environnement de production à distance:

  • Évaluer la compatibilité du matériel: Inventaire de tous les équipements audio aux deux extrémités : consoles de mixage, boîtes de scène, préamplis de microphone, codecs, panneaux d'interphone. Confirmez le support AES67 via l'implémentation native ou la mise à niveau du firmware. Les appareils sans AES67 peuvent nécessiter des convertisseurs ou des boîtes de passerelle (p. ex., pont Dante à AES67). Certains appareils plus anciens peuvent supporter AES67 seulement de manière limitée, comme les paramètres de flux fixes ou les profils PTP restreints.
  • Concevoir le réseau IPPour un flux stéréo typique (48 kHz, 24 bits), la bande passante est d'environ 2,9 Mbps par canal; plan pour la salle de tête. Pour les liaisons à distance, un circuit MPLS dédié ou un cellulaire lié avec des garanties QoS est recommandé sur l'internet public en raison de la perte de jitter et de paquets. La conception du réseau doit également tenir compte de la nature éclatement du trafic RTP: même si le débit moyen est prévisible, la taille des paquets et le timing inter-paquets peuvent varier en fonction de l'alignement PTP et de la congestion du réseau.
  • Configurer le protocole de précision (PTP): Désigner une horloge grandmaster (par exemple, en utilisant un oscillateur discipliné GPS ou un maître conforme AES67- / ST 2059). S'assurer que tous les appareils du réseau sont configurés dans le même domaine PTP (par défaut 0 pour AES67). Utiliser des horloges limites ou des horloges transparentes pour limiter la charge PTP sur les grands réseaux. Dans les scénarios de production à distance où le grandmaster est à un emplacement central, le chemin WAN doit être conçu pour transporter des messages PTP avec une variation de délai faible; sinon, les esclaves peuvent perdre le verrou ou accumuler des erreurs de synchronisation.
  • Définir les paramètres QoS et stream: Marquez tous les trafics audio AES67 avec DSCP EF (46) ou AF41 (34) aux niveaux de commutateur et de routeur. Configurez des adresses multicast (239.192.x.x) et des descriptions de session (SDP) pour chaque flux. De nombreux appareils génèrent automatiquement des fichiers SDP ; ceux-ci peuvent être échangés entre des emplacements distants via le transfert de fichiers ou l'API. Le SDP contient tous les paramètres nécessaires pour décoder le flux : adresse IP, port, type de charge utile, taux d'échantillonnage, profondeur de bits, nombre de canaux et informations de synchronisation PTP.
  • Essais d'interopérabilitéAvant de passer en direct, effectuer des tests de bout en bout en utilisant des signaux de référence (p. ex. tonalité 1 kHz, silence, matériel de programme). Mesurer la latence entre les points de code et de décodage en utilisant un outil logiciel ou un comparateur matériel. Sonde pour perte de paquets, duplications, ou décalages de temps. Vérifier que le verrouillage PTP est maintenu à travers les reboots et les changements de réseau. Il est également sage de tester des scénarios de décrochage, comme une panne d'horloge grandmaster ou une panne de liaison réseau, pour s'assurer que les flux audio continuent sans problèmes sonores.

Défis dans les déploiements à distance de l'AES67

La production à distance introduit souvent des conditions de réseau différentes d'une usine de studio contrôlée. La latence du WAN peut dépasser 50 ms, rendant impossible la redondance sans tampon de sous-cinq ms AES67. La perte de paquets sur les liens Internet provoque des abandons à moins que la correction d'erreur avancée (FEC) ou les flux redondants ne soient utilisés. Certains radiodiffuseurs optent pour une redondance transparente de ST 2022-7 sur deux chemins différents pour protéger contre les défaillances.

Un autre défi commun est la nature asymétrique de nombreuses connexions WAN. Bien que la bande passante de téléchargement soit généreuse, la capacité de téléchargement est souvent limitée, ce qui peut créer des goulots d'étranglement lorsque plusieurs flux audio doivent être envoyés d'un site éloigné à un centre de production. Les ingénieurs doivent calculer avec soin la bande passante ascendante agrégée requise et s'assurer que la connexion peut la maintenir sans perte de paquets.

Intégration de AES67 aux flux de travail audio basés sur le cloud

L'avènement de la production de cloud – où le mélange, le suivi et le traitement se produisent sur des machines virtuelles dans les centres de données – ajoute une autre couche de complexité. Les flux audio basés sur le cloud, conçus à l'origine pour les multidiffusions en temps réel sur les réseaux locaux, doivent être adaptés pour le transport unicast sur l'internet public tout en maintenant une faible latence et la précision de l'horloge.

Portails Cloud et points d'extrémité virtualisés

Plusieurs fournisseurs offrent désormais des logiciels de terminaux AES67 (p. ex., la carte son virtuelle RAVENNA de Layo, le NTP Anubis de Merging, ou des appareils matériels comme le pont Dante Domain Manager). Ces appareils convertissent les flux AES67 en formats consommables par les applications de traitement en nuage (p. ex., les DAW, les moteurs de mélange automatisés ou les routeurs virtuels).

  • Codec sur site: Recevoir l'audio analogique ou numérique et encoder vers AES67/RTP sur local LAN.
  • Porte de l'extrémité: Traduit en unicast, ajoute FEC, tampons pour compenser la latence variable du WAN, et applique le chiffrement (par exemple, AES-256 sur SRTP). La passerelle de bord est souvent un appareil matériel dédié ou une instance logicielle durcie fonctionnant sur un serveur de bord bien fourni.
  • Récepteur nuageux: Une machine virtuelle utilisant un pilote audio à faible latence qui décode le flux AES67 et présente de l'audio au moteur de production du cloud (par exemple via ASIO ou ALSA). Le récepteur cloud doit être situé dans un centre de données avec un accès à faible latence à la passerelle de bord ; AWS Direct Connect ou Azure ExpressRoute peut fournir une connectivité dédiée et prévisible.
  • Chemin de retour: Processus similaire en sens inverse, avec le flux de sortie du nuage renvoyé à plusieurs endroits distants. Le chemin de retour transporte souvent des mixes, des signaux et des signaux d'intercom, et doit être synchronisé avec le chemin avant pour éviter la dérive.

Une approche émergente consiste à exécuter l'ensemble du paramètre AES67 comme un microservice conteneurisé dans le cloud, en utilisant des technologies comme Docker ou Kubernetes. Cela permet aux radiodiffuseurs d'évaluer les instances de paramètre dynamiquement en fonction de la demande de production, de faire tourner des récepteurs supplémentaires pour les grands événements et de réduire les périodes de calme.

Meilleures pratiques pour l'intégration du cloud

  • Utiliser des ressources informatiques spécifiques: Les machines virtuelles Cloud doivent avoir des performances réseau déterministes ; choisir des types d'instance avec accélération réseau (par exemple, AWS Elastic Network Adapter) et éviter les obligations partagées pour le travail critique latence. Réservez les cœurs CPU pour PTP en temps réel et le traitement audio. L'hyperthreading devrait être désactivé sur les hôtes exécutant des charges audio en temps réel pour éviter que les fils de friponnement ne se déclenchent.
  • Sécurité du transport audio Dans les flux de travail en nuage, toujours tunnel AES67 via un VPN ou utiliser SRTP (Secure RTP) pour empêcher les écoutes et les manipulations. L'authentification de bout en bout doit être implémentée à l'aide de certificats ou de clés pré-partagées. Pour les applications de haute sécurité telles que les nouvelles en direct ou les paris sportifs, la gestion des clés de chiffrement doit suivre un modèle de confiance zéro où chaque flux utilise une clé unique et éphémère.
  • Surveiller et adapter: Surveillance continue des jitters RTP, des numéros de séquence et de l'offset PTP est crucial. Déployer des agents de diagnostic réseau aux deux extrémités ; augmenter automatiquement la profondeur du tampon lorsque jitter dépasse les seuils. Utilisez les services cloud comme AWS CloudWatch ou Azure Monitor pour suivre la santé des flux audio.
  • Normaliser sur unicast: Alors que AES67 prend en charge nativement les centres de données multicast, les centres de données cloud ne disposent généralement pas de routage multicast. Forcent tous les flux AES67 à unicast (IP à destination unique). Cela simplifie également les règles de pare-feu ( ports UDP 5004, 5005 pour RTP et RTCP).
  • Plan de redondance des horloges Dans un déploiement en nuage, le grand maître PTP peut être une instance virtualisée qui utilise une horloge logicielle disciplinée par NTP ou GNSS via une API time-as-a-service. Cependant, les horloges virtualisées peuvent dériver sous une lourde charge CPU. Déployer des grands maîtres redondants dans différentes zones de disponibilité et utiliser le meilleur Algorithme Master Clock (BMCA) pour échouer automatiquement si le maître primaire devient inaccessible.

Synchronisation de l'adresse dans le WAN

L'un des obstacles les plus importants pour le cloud AES67 est de maintenir la synchronisation PTP lorsque l'horloge grandmaster n'est pas accessible par des liens WAN peu fiables. Les solutions courantes comprennent le déploiement d'un grand maître local sur chaque site discipliné par GNSS (par exemple GPS, Galileo), ou l'utilisation d'un esclave PTP logiciel qui converge vers un maître basé sur le cloud via le protocole IEEE 1588 avec des profils PTP appropriés.

Pour les diffuseurs qui ont besoin d'une synchronisation par sondage sur les continents, l'extension White Rabbit à PTP offre une précision de sous-nanoseconde sur WAN. Alors que White Rabbit est plus courante dans les applications scientifiques et financières, son utilisation en radiodiffusion est en croissance, surtout pour les productions distribuées à grande échelle où plusieurs sites éloignés contribuent à un seul mélange en direct. Le coût et la complexité du matériel White Rabbit sont toujours importants, mais à mesure que la technologie mûrit, il peut devenir la défaut pour la production à distance haut de gamme.

Proofing futur avec AES67 et ST 2110

AES67 n'est pas une norme statique. Il constitue la base audio de la suite SMPTE ST 2110, qui apporte des données vidéo, audio et accessoires sur IP. Alors que les radiodiffuseurs progressent vers la production tout-IP, ST 2110-30 (audio) hérite exactement AES67, ce qui signifie que tout investissement dans l'infrastructure AES67 est aujourd'hui entièrement compatible avec les futurs systèmes ST 2110. De plus, la révision AES67-2018 a ajouté le support pour des taux d'échantillonnage plus élevés (96 kHz) et une meilleure gestion de la redondance.

L'évolution d'AES67 se croise également avec les standards audio émergents basés sur IP comme AES72 (architecture de contrôle ouvert pour les réseaux AoIP) et les travaux de l'AES sur le transport audio pour les audio immersifs et les audio objet. Comme les diffuseurs adoptent des formats tels que Dolby Atmos et MPEG-H, la couche de transport doit gérer plusieurs objets audio et flux de métadonnées.

Exemples pratiques de l'industrie

Les principaux diffuseurs comme la BBC et NBC Sports ont déployé AES67 pour des postes de commentaires à distance, permettant aux talents freelance de se connecter à partir de studios d'origine utilisant des interfaces Ravenna ou Dante. La production audio pour les événements e-sports en direct utilise de plus en plus AES67 pour lier les consoles audio de jeu avec des logiciels de mixage basés sur le cloud.

Une autre adoption notable est la diffusion de musique en direct, où les festivals et les salles de concert utilisent AES67 pour distribuer des sons multicanaux aux ingénieurs de mixage à distance, ce qui leur permet de créer des mixages de diffusion de n'importe où dans le monde. La précision de synchronisation de PTP garantit que tous les instruments et microphones vocaux restent en phase, même lorsque l'ingénieur surveille le traitement en nuage.

Conclusion

AES67 est devenu le pont indispensable entre les écosystèmes différents d'AoIP, ouvrant de nouvelles possibilités pour la production audio à distance et en nuage. En maîtrisant ses exigences techniques – synchronisation PTP, marquage QoS, gestion SDP et conception de réseau – les diffuseurs peuvent construire des flux audio flexibles et interopérables qui vont d'une seule salle de contrôle à une infrastructure cloud globale. AES67, qui continue de se diriger vers une production entièrement logicielle et IP, constitue une base stable et à l'avenir qui restera la pierre angulaire du transport audio professionnel pour les années à venir.

Pour plus de détails, consulter le site Document type AES67 disponible auprès de la Société d'ingénierie audio, Spécifications SMPTE ST 2110-30 pour les notes d'applications audio et de fournisseurs relatives à la vidéo, Guide d'Audinate pour configurer AES67 sur les appareils Dante ou les livres blancs de Lavo RAVENNA. Ces ressources offrent des détails techniques plus détaillés pour les ingénieurs qui planifient leur prochain déploiement AES67.