Qu'est-ce que l'AES67 – et pourquoi est-ce important?

Chaque fabricant – Dante, RAVENNA, Livewire, Q-LAN – utilise des protocoles propriétaires qui ne peuvent pas se parler. En 2013, la Société Audio Engineering a publié AES67, une norme d'interopérabilité ouverte qui définit un ensemble commun de protocoles réseau afin que les appareils de différents fournisseurs puissent échanger des sons de haute qualité sur des réseaux IP standards. AES67 ne remplace pas ces systèmes propriétaires; il agit comme une « couche de bridging » qui leur permet de coexister et d'interagir sans exiger de chaque appareil de prendre en charge une plate-forme fermée.

AES67 est maintenant largement adopté dans les studios de diffusion, de son en direct, d'enregistrement, d'AV d'entreprise, et même certaines applications sonores installées. Il est le fondement d'autres normes AoIP comme SMPTE ST 2110-30 et contribue à la poussée plus large vers la production tout-IP. Comprendre l'architecture et les protocoles AES67 , ce n'est pas seulement un exercice académique – il affecte directement votre capacité à concevoir, dépanner et à mettre à l'échelle un réseau audio moderne.

Composantes essentielles de l'architecture AES67

Un réseau AES67 repose sur quatre piliers essentiels : infrastructure réseau, synchronisation, transport des médias et découverte. Chaque composant repose sur des normes bien établies du Groupe de travail sur l'ingénierie d'Internet (IETF), qui maintient le système à la fois fiable et agnostique pour les fournisseurs.

1. Infrastructure réseau

AES67 fonctionne sur Ethernet standard, mais parce qu'il transporte des sons isochrones en temps réel, le réseau doit répondre à certaines exigences minimales. Snooping des IGPG gérer efficacement les groupes multicast, DiffServ QoS (Point de code de services différenciés) pour prioriser les paquets audio, et Isolation VLAN Bien que 1 Gbps soit typique, les grandes stations de radiodiffusion peuvent utiliser 10 Gbps ou plus. Les cadres Jumbo (jusqu'à 9000 octets) sont facultatifs mais recommandés pour réduire les frais généraux de paquets.

Pour un fonctionnement fiable, les ingénieurs en réseau devraient permettre files d'attente prioritaires strictes (habituellement CoS 4 ou 5 pour PTP, CoS 3 pour RTP audio) et assurer un acheminement de faible latence. Les commutateurs ne devraient pas introduire plus de quelques microsecondes de jitter, parce que la synchronisation PTP de AES67 , tolère seulement de petites variances de synchronisation.

2. Synchronisation – Protocole de précision temps (PTP)

Tous les appareils AES67 doivent être synchronisés avec une horloge commune. La norme mandate IEEE 1588-2008 Precision Time Protocol (souvent appelé PTPv2) en utilisant la Profil AES67. Contrairement au PTP générique, le profil AES67 spécifie un numéro de domaine par défaut (domaine 0) et utilise une messagerie en deux étapes avec multicast. L'horloge grandmaster est généralement un serveur PTP dédié, mais tout périphérique sur le réseau – un microphone, une console de mixage ou un pont – peut devenir le grandmaster s'il a une source d'horloge stable.

Les Meilleur Algorithme de l'horloge principale (BMCA) sélectionne automatiquement l'horloge la plus précise, minimisant la configuration humaine. Dans la pratique, les radiodiffuseurs verrouillent souvent tous les domaines PTP à une référence GPS ou GNSS, permettant une synchronisation sous microsecondes sur de grandes installations.

3. Transport des médias – Protocole de transport en temps réel (RTP)

Les échantillons audio sont encapsulés dans des paquets RTP et transmis sur UDP. AES67 supporte les taux d'échantillonnage communs : 44.1, 48 et 96 kHz, avec des profondeurs de bits de 16 ou 24 bits (et un point flottant de 32 bits pour une utilisation intra-studio).

Le format de charge utile RTP est L16 ou L24 AES67 permet également l'encodage μ-law pour la compatibilité avec les systèmes de télécommunications plus anciens, mais qui est rarement utilisé dans l'audio professionnel. Les paquets sont envoyés sous forme de flux UDP multicast à une adresse de groupe; les récepteurs s'abonnent via IGMP. Protocole de contrôle RTP (RTCP) est utilisé pour les statistiques hors bande, mais pas pour la récupération d'horloges, qui est entièrement gérée par PTP.

La latence dans AES67 est configurable. La valeur par défaut recommandée est de 1 ms (permettant environ 48 échantillons par paquet à 48 kHz), mais certains équipements supportent 0,125 ms pour la surveillance de la latence ultra-faible ou 4 ms pour les connexions moins critiques sur les réseaux encombrés.

4. Découverte et enregistrement

Les appareils doivent savoir quels flux sont disponibles sur le réseau. AES67 s'est initialement appuyé sur le Protocole d'annonce de session (PAS), qui diffuse périodiquement des descriptions de flux (format SDP) à une adresse multicast bien connue (224.2.127.254). SAP est simple et léger, mais il peut être bavard sur de grands réseaux.

D'autres méthodes de découverte coexistent avec AES67: RTSP (Real Time Streaming Protocol) peut être utilisé pour le contrôle de session, et des extensions plus récentes comme MDNS/DNS-SD Le point clé est que AES67 ne définit pas lui-même un protocole de découverte – il ne fait que mandater les flux pouvant être décrits à l'aide d'un fichier de protocole de description de session (SDP). Les fabricants sont libres de mettre en œuvre tout mécanisme de découverte qui transmet des informations SDP, tant qu'un périphérique tiers peut l'analyser.

Principaux protocoles en détail

Bien que les quatre composantes principales constituent l'architecture, plusieurs protocoles sous-jacents méritent un examen plus approfondi. Comprendre comment ils interlockent est ce qui sépare un déploiement AES67 fonctionnel d'un déploiement problématique.

PTP (Protocole de précision de temps) – le battement du cœur

PTP fonctionne en échangeant des messages horodatés entre le grand maître et toutes les horloges esclaves. Le profil AES67 utilise une opération en deux étapes : le grand maître envoie un message Sync, puis un message Follow Up contenant l'heure de départ exacte. Les esclaves utilisent cela pour calculer le décalage et ajuster leurs propres horloges via un algorithme servo.

Sur la plupart des commutateurs gérés, les messages PTP doivent être considérés comme prioritaires et ne jamais être retardés par le traitement en magasin et en avant. Les horloges de bordure ou les horloges transparentes (TC) sur les commutateurs peuvent compenser le retard de la passerelle, mais dans les petits réseaux, une approche ordinaire en deux étapes sans TC est suffisante. La norme exige que les dispositifs d'extrémité se verrouillent dans les 2 secondes suivant le démarrage et maintiennent la dérive en dessous d'une microseconde sur un intervalle d'une seconde – étanche, mais réalisable avec une bonne conception.

RTP (Protocole de transport en temps réel) – le transporteur de charge utile

Les paquets RTP portent un en-tête contenant le numéro de séquence, l'horodatage et le SSRC (identificateur de source de synchronisation). Le profil AES67 spécifie un temps de paquet maximal de 4 ms, avec 1 ms de préférence. Puisque RTP tourne sur UDP, il n'y a pas de retransmission; la perte de paquet doit être traitée en amont (par exemple via des flux redondants ou FEC, bien que AES67 ne mandate pas FEC).

Un piège commun : des temps de paquets mal appariés entre l'expéditeur et le récepteur peuvent provoquer des abandons audio. Configurez toujours les deux extrémités au même paramètre --ptime-- dans le fichier SDP. Vérifiez également que le chemin réseau ne dépasse pas le temps-à-vie RTP (TTL); AES67 recommande un TTL d'au moins 10 pour les petits réseaux.

SIP (Protocole d'ouverture de session) – un recouvrement utile

AES67 mentionne le SIP comme une méthode possible pour la gestion de session et la découverte de flux, mais c'est rarement l'approche principale. Dans la pratique, la plupart des appareils AES67 dépendent de SAP ou d'interfaces web propriétaires. SIP est plus commun dans les interphones AoIP orientés vers les télécommunications comme VoIP ou SIP qui s'intègrent avec les ponts AES67.

Avantages de l'AES67 dans le monde réel

La prestation principale est interopérabilité sans verrouillage. Une installation de diffusion utilisant RAVENNA pour les liaisons studio-transmetteur peut accepter les microphones équipés de Dante; une console son en direct peut tirer un flux d'un Q-SYS DSP. AES67 agit comme un -traducteur universel qui élimine le besoin de matériel de passerelle dédié dans de nombreux cas.

Parmi les autres avantages, on peut citer :

  • Échelle: Puisque AES67 utilise des multidiffusions IP standard, vous pouvez ajouter des centaines de flux tant que vos commutateurs peuvent gérer le nombre de groupes multidiffusion et la bande passante. Il n'y a pas de frais de licence par canal.
  • Rentabilité : Aucun matériel réseau propriétaire n'est nécessaire – les commutateurs hors-sol de bonne qualité fonctionnent lorsque configurés correctement.
  • Protection future : Comme SMPTE ST 2110 devient la norme de diffusion, AES67 (qui est identique à la partie audio de ST 2110-30) est déjà là. Un studio qui construit un réseau AES67 aujourd'hui peut migrer vers ST 2110 complet vidéo-over-IP plus tard avec des changements minimes.
  • Fiabilité: L'horlogerie basée sur PTP élimine les problèmes de dérive et de jitter qui affligent les anciens réseaux isochrones. La tolérance AES67 , pour la perte de paquets (jusqu'à 1% sans défaillance critique dans les systèmes bien buffered), ajoute de la résilience.

Guide de mise en œuvre – Construire votre premier réseau AES67

Déployer AES67 nécessite plus que de simplement brancher les appareils. Suivez cette approche structurée pour éviter les maux de tête courants.

Étape 1: Vérifier la compatibilité de l'appareil

Tous les appareils qui revendiquent -AES67-A sont entièrement conformes. Consultez la liste d'interopérabilité AES67 (maintenue par l'Alliance de réseautage multimédia). Si vous mélangez Dante et RAVENNA, par exemple, assurez-vous que le module Dante supporte le mode optionnel AES67 (disponible sur de nombreux modèles plus récents).

Étape 2: Concevoir la topologie du réseau

Utiliser un topologie de l'étoile Avec un interrupteur central et des interrupteurs de bord, ou une feuille de colonne vertébrale pour les grandes usines. Activer l'inversion IGMP et la requête sur chaque VLAN qui transporte de l'audio. Contrôle séparé et trafic audio: VLAN dédiés pour PTP et flux multicast réduisent le risque de mauvaise configuration.

Attribuer des adresses IP statiques aux appareils critiques (grand-maître horloge, unités d'entrée/sortie fixes). DHCP est acceptable pour les paramètres si le bail est long, mais éviter les adresses dynamiques pour les grands-maîtres PTP.

Étape 3: Configurer PTP

  • Désigner un grand maître principal (p. ex., un serveur PTP verrouillé par GPS).
  • Assurez-vous que tous les appareils utilisent le profil AES67 (IEEE 1588-2008, 2 étapes, domaine 0 par défaut, multicast).
  • Réglez tous les commutateurs en mode horloge transparent (si pris en charge) ou en mode horloge limite. Au minimum, ils ne doivent pas filtrer les messages PTP; assurez-vous que PTP Ethernet multicast est autorisé (adresse MAC 01-1B-19-00-00-00).
  • Surveillez le décalage PTP sur chaque appareil – il devrait être de < 1 μs. Si elle dépasse 10 μs, il y a un problème de synchronisation du réseau (délais de commutation, surcharge du processeur ou embrouillement du mauvais câblage).

Étape 4: Mettre en place des flux

Utilisez l'interface utilisateur web de l'appareil ou le logiciel de contrôle pour créer un flux d'émetteur. Capturez le fichier SDP (souvent téléchargeable sous forme de fichier .sdp). Sur le récepteur, importez le SDP ou utilisez la découverte automatique (SAP/mDNS). Vérifiez que le flux apparaît sur le réseau : vous pouvez utiliser Wireshark avec le filtre d'affichage pour voir les paquets.

Étape 5: Essai et validation

  • Mesurer la latence entre émetteur et récepteur en utilisant une tonalité et un oscilloscope, ou un outil d'analyse RTP.
  • Tester la résilience de perte de paquets en débranchant brièvement un câble; l'audio ne doit pas glisser pour les paquets perdus de 1 à 2 ms. Si cela se produit, augmenter légèrement la taille du tampon (jusqu'à 4 ms).
  • Vérifiez que le verrouillage PTP est maintenu lorsque vous ajoutez plusieurs flux. Une erreur courante est de surcharger le processeur de commutation avec des messages PTP sur un port mal configuré; utilisez le commutateur QoS pour prioriser le PTP.

Étape 6: Documenter votre configuration

Enregistrer chaque périphérique , rôle PTP, flux SDP, et la configuration de port de commutation. Ceci est inestimable quand un composant échoue et a besoin de remplacement. Sans documentation, la reconstruction d'un grand réseau AES67 à partir de zéro est presque impossible.

Pièges communs – et comment les éviter

  • Conflits de chronométrage PTP : L'exécution de plusieurs domaines PTP sur le même réseau (p. ex., système de films utilisant le domaine 0 alors qu'une console de son en direct utilise le domaine 1) peut causer de la confusion.
  • Snooping IGMP non activé: Sans cela, l'audio multicast inonde chaque port de commutation, causant une perte de paquets et une charge inutile.
  • QoS mal configuré : Si PTP est retardé derrière un éclatement de trafic FTP, la synchronisation dérive. Utilisez des files d'attente prioritaires strictes (DSCP 46 pour PTP, DSCP 34 ou 36 pour RTP audio).
  • Mauvaise adéquation du cadre Jumbo: Si le commutateur prend en charge les cadres jumbo mais que l'expéditeur ne le fait pas, vous pouvez obtenir la fragmentation. Gardez tous les appareils sur le même MTU (1500 ou 9000).
  • Ignorer les réseaux: Même avec un PTP parfait, les tampons RTP doivent être configurés pour absorber les jitters réseau. Utilisez -ptime-test en accord avec votre réseau-tâche le plus mauvais cas.

Comparaison avec d'autres normes AoIP

AES67 n'est pas un produit; c'est une norme de pont. Dante domine le marché AV installé et prend en charge AES67 comme mode secondaire. RAVENNA est populaire en radiodiffusion et utilise déjà AES67 comme son transport audio natif. Câbles vivants+ (de Wheatstone) est construit sur AES67. Q-LAN (QSC) prend également en charge AES67.

La différence clé : dans un environnement multivendeur, AES67 assure qu'ils parlent tous la même langue. Lorsque vous avez besoin de la latence la plus basse (sous-0,25 ms), les systèmes propriétaires ont encore un bord, mais pour 99 % de l'utilisation professionnelle, AES67 , 1 ms est plus que adéquat.

L'avenir de l'AES67

La société Audio Engineering continue d'évoluer. AES67-2022 a ajouté le support pour le flotteur 32 bits, clarifié la gestion redondante du flux, et a mis à jour le profil PTP pour s'aligner sur IEEE 1588-2019. Alliance pour les réseaux de médias AES67 restera l'épine dorsale audio. Pour tout ingénieur qui conçoit aujourd'hui un système audio en réseau, AES67 n'est pas seulement un beau à avoir, c'est le pari le plus sûr pour la compatibilité à long terme.

Pour plonger plus profondément, consultez le Norme AES67 (AES67-2018/R2023), les RTP RFC (RFC 3550)et les Norme IEEE 1588-2008. Guides pratiques de Authénaté et RAVENNA Avec une solide compréhension de l'architecture et des protocoles AES67, vous pouvez concevoir un réseau audio à la fois performant et vraiment ouvert.