Assurer la qualité du service (QoS) dans les environnements de diffusion audio AES67 est essentiel pour maintenir une transmission audio fiable et de haute qualité sur les réseaux. AES67 est une norme pour l'interopérabilité des réseaux audio-over-IP de haute performance, couramment utilisés dans la radiodiffusion, les événements en direct et les systèmes audio professionnels.

Comprendre l'AES67 et le rôle de la QS

AES67 est une norme audio-over-IP de Layer 3 qui permet l'interopérabilité entre différents systèmes AoIP (comme Dante, RAVENNA, et Livewire) en utilisant des principes standard de réseau IP. Bien que cette flexibilité soit puissante, elle rend également les flux AES67 vulnérables aux mêmes problèmes de réseau qui affectent tout trafic IP : congestion, jitter, perte de paquets, et latence variable.

Dans un réseau convergent typique, les données provenant des transferts de fichiers, de la navigation sur le Web, de la vidéoconférence et d'autres applications sont en concurrence pour la même bande passante. Sans QoS, un flux audio peut être retardé ou abandonné à tout interrupteur, ce qui entraîne des glissades sonores, des pops ou des abandons complets.

Fondation technique de QoS pour AES67

Priorité des paquets avec marquage DSCP

La composante la plus critique de la QoS pour AES67 est Point de code de services différencié (CPSD) marquage. DSCP est un champ dans l'en-tête IP qui indique aux périphériques réseau comment traiter un paquet. AES67 prescrit l'utilisation de valeurs DSCP spécifiques pour distinguer les flux audio d'autres trafics. EF (transmission accélérée, valeur 46) pour les paquets de charge utile audio et CS3 (Sélecteur de classe 3, valeur 24) pour la synchronisation PTP (Precision Time Protocol). Les commutateurs et les routeurs doivent être configurés pour honorer ces marquages en les plaçant dans des files d'attente hautement prioritaires et en fournissant une transmission à faible latence.

Pour AES67, il est essentiel de configurer chaque commutateur le long du chemin de données pour respecter les valeurs DSCP. Si un commutateur traite les paquets EF comme étant le meilleur effort, le flux audio peut en souffrir. La configuration de bout en bout de DSCP est la base d'une politique QoS fiable.

Segmentation réseau avec VLAN

Dédicace d'un Réseau virtuel (VLAN) En plaçant tous les appareils AES67 (microphones, consoles de mélange, amplificateurs, convertisseurs) sur un seul VLAN et en utilisant l'analyseur IGMP pour gérer des groupes multicasts, vous réduisez les risques de trafic non audio interférant avec le flux. La segmentation VLAN simplifie également l'application de la politique QoS, car vous pouvez appliquer une seule politique QoS à l'ensemble du VLAN audio.

Il est courant de créer un VLAN vocal pour le trafic AoIP, séparé du VLAN de données (pour le trafic informatique général) et du VLAN de gestion. Cette séparation améliore également la sécurité, car les appareils AES67 ne sont pas directement accessibles depuis le réseau d'entreprise à moins que vous le souhaitiez. Cependant, assurez-vous que le routeur ou le commutateur Layer 3 qui connecte les VLANs peut gérer le routage inter-VLAN avec un minimum de latence si votre système audio doit communiquer avec des réseaux externes (p. ex., flux de diffusion à distance).

Répartition de la largeur de bande et façonnage du trafic

Les flux audio AES67 sont généralement emballés dans des paquets RTP. Un seul flux non compressé de 48 kHz, 24 bits, 2 canaux consomme environ 2,784 Mbps de bande passante réseau (y compris IP/UDP/RTP). Démarche du trafic et police Réserve un pourcentage de bande passante minimum (p. ex. 30 à 50%) pour le VLAN audio ou pour les paquets avec marquage DSCP EF en utilisant des fonctionnalités comme la formation d'évacuation ou le taux d'information engagé (CIR).

Attention à ce que la bande passante surréservée peut priver d'autres applications. Au lieu de cela, prioriser le trafic audio en utilisant une file d'attente prioritaire stricte (PQ) ou une file d'attente à faible latence (LLQ) tout en permettant au trafic le mieux-effort d'utiliser la capacité de gauche. Une approche commune est de configurer une file d'attente prioritaire stricte pour les paquets DSCP EF avec un taux de police pour empêcher un périphérique mal configuré d'inonder la file d'attente.

Synchronisation de l'horloge et PTP

AES67 s'appuie sur IEEE 1588-2008 Protocole de précision (PTP) Si les paquets PTP sont retardés ou brouillés, les échantillons audio peuvent être mal alignés, ce qui entraîne des clics ou des abandons. Pour protéger les paquets PTP, les paquets CS3 (DSCP 24) doivent être placés dans une file d'attente hautement prioritaire, bien que généralement pas la même file d'attente prioritaire stricte que l'audio, afin d'éviter toute discorde entre le trafic audio et la synchronisation.

Et si vous voulez horloges limites et horloges transparentes dans le réseau pour améliorer la précision PTP sur plusieurs interrupteurs de saut. Les interrupteurs à grande vitesse avec support d'horodatage matériel peuvent réduire considérablement le jeu PTP, ce qui permet une plus grande stabilité audio.

Jitter Buffers et gestion des latences

Même avec une QoS parfaite, certains jitter résiduels restent dus à des retards de commutation et des différences de longueur de câble. Couvertures de sécurité En augmentant la taille du tampon de jitter, le système est plus tolérant aux irrégularités du réseau, mais ajoute de la latence. Pour les applications en temps réel comme le renforcement sonore en direct, la latence totale doit rester en dessous de 1-2 ms (délai réseau) plus le délai de tampon. Un tampon de jitter AES67 typique est de 4-10 échantillons audio (0,08–0,2 ms à 48 kHz), mais peut être augmenté dans des environnements moins stricts.

Mécanismes d'évitement de la congestion comme WRED (Détection précoce aléatoire pondérée) peut aider à prévenir les chutes de queue en décrochant aléatoirement des paquets moins prioritaires avant que la file ne se remplisse, signalant les flux TCP à reculer. Pour AES67, qui utilise UDP, WRED a un effet limité, mais il peut encore protéger contre les rafales de trafic.

Mise en oeuvre de la QS dans les réseaux AES67

Configuration des commutateurs et des routeurs réseau

Commencez par sélectionner les commutateurs gérés qui prennent en charge la confiance DSCP, les files d'attente prioritaires (généralement 4-8 files d'attente par port) et le marquage VLAN (IEEE 802.1Q).

  1. Activer Fonds du DSCP sur tous les ports où les périphériques AES67 sont connectés. Ne définissez pas le DSCP par défaut à moins que l'appareil ne puisse pas marquer ses propres paquets (ce qui est rare pour AES67).
  2. Carte des valeurs DSCP pour les files d'attentes de sortie: DSCP EF → file d'attente 4 (priorité restreinte), DSCP CS3 → file d'attente 3 (priorité élevée), DSCP AF41 ou autres marques audio liées → file d'attente 2, best-effort → file d'attente 1.
  3. Configuration la formation ou la police sur la file d'attente prioritaire stricte pour limiter le trafic EF à, par exemple, 20% de la capacité de liaison, ce qui empêche un expéditeur mal comportemental de mourir de faim d'autres files d'attente.
  4. Activer Snooping des IGPG et Détonation des MLD (si IPv6) pour limiter le trafic audio multicast uniquement aux ports qui se sont abonnés, ce qui réduit les inondations multicast inutiles.
  5. Si vous utilisez PTP, envisager de permettre Commutation PTP-aware (mode horloge limite) ou utilisant l'horodatage matériel pour améliorer la précision.

Définir les valeurs DSCP pour AES67

La plupart des appareils conformes à l'AES67 vous permettent de configurer le marquage DSCP soit via une interface web, un contrôle logiciel ou un SNMP. Confirmez que chaque appareil envoie des paquets de charge utile audio avec DSCP EF (46) et PTP avec DSCP CS3 (24). Si un appareil ne peut pas être configuré pour utiliser ces valeurs, vous devrez peut-être noter DSCP au port de commutation d'accès.

Sur un commutateur Cisco, une remarque typique ACL ressemblerait à : (ports RTP standard AES67) suivi d'une carte de classe qui définit DSCP EF. Gardez la configuration cohérente sur tous les commutateurs pour éviter les erreurs d'appariement.

Configuration et isolement VLAN

Créer un VLAN dédié au trafic AES67, par exemple, VLAN 100 – Audio. Affecter tous les ports de périphérique AES67 à ce VLAN comme ports d'accès (intagrées) ou comme ports de réseau avec le VLAN audio comme VLAN natif/intagné si l'appareil prend en charge le marquage VLAN. Assurez-vous que le trafic de gestion de ces appareils (si nécessaire) va à un VLAN de gestion distinct pour éviter les protocoles de contrôle de radiodiffusion sur le VLAN audio.

Sur les circuits interinterrupteurs, utilisez le marquage IEEE 802.1Q et assurez-vous que le VLAN audio est autorisé. Configurez les commutateurs pour prioriser le trafic à partir du VLAN audio en fonction des marques DSCP (pas de priorité VLAN, puisque AES67 utilise L3 DSCP plutôt que L2 802.1p).

Surveillance de la qualité et diagnostics

De nombreux appareils AES67 rapportent des statistiques RTCP (RTT, jitter, taux de perte de paquets). La collecte de ces données à partir des paramètres donne une vue de première main de la qualité audio. De plus, utilisez SNMP pour surveiller les erreurs d'interface de commutation, les rejets et les chutes de file d'attente. Des outils comme Wireshark peuvent capturer des flux RTP pour une analyse détaillée, bien que cela devrait être fait dans un laboratoire pour éviter d'affecter le trafic de production.

Mettre en place des alertes pour la perte de paquets > 0,1% ou de jitter > 1 ms, car celles-ci précèdent souvent les artefacts audibles.

Meilleures pratiques pour une EES67 fiable QoS

Essais préalables au déploiement

Avant de passer à la scène, simulez la charge réseau complète dans un environnement de test. Utilisez des générateurs de trafic pour créer des flux de données concurrents et vérifier que l'audio AES67 reste propre.

  • Transfert de données de base (p. ex. copie de fichier, diffusion vidéo).
  • Trafic de radiodiffusion (ARP, DHCP, mises à jour de routage multicast).
  • Défauts de liaison (débrancher un interrupteur ou un câble pour tester la redondance).

La mesure de la perte de paquets RTP et des tests d'écoute avec audio critique (p. ex. musique classique, parole orale) révélera des problèmes subtils qui peuvent ne pas apparaître dans les tests de tonalité simples.

Stratégies de redondance et d'échec

Pour les systèmes critiques, mettre en place une redondance réseau à plusieurs niveaux : alimentations redondantes, agrégation de liaisons (LACP) pour une plus grande tolérance à la bande passante et aux défauts, et maîtrises d'horloge redondantes pour PTP. Redondance du flux audio Pour ce faire, il faut envoyer deux flux identiques (primaire et de sauvegarde) sur différents chemins IP ou utiliser des groupes multicasts avec le feu rapide IGMP. STP (Spanning Tree Protocol) devrait être soigneusement réglé pour minimiser le temps de convergence; utiliser le STP rapide (RSTP) ou le STP multiple (MSTP) avec un placement prudent de la passerelle racine.

Documentation et gestion du changement

Maintenez une documentation détaillée de toute la configuration QoS : ID VLAN, mappages DSCP, tâches de file d'attente, taux de police et paramètres des appareils. Utilisez le contrôle de version pour les configurations de commutateurs. Chaque fois qu'un changement est effectué (p. ex., ajout d'un nouvel appareil, mise à jour du firmware), suivez un processus de gestion du changement qui inclut d'abord des tests sur un réseau non-production.

Collaboration entre les équipes AV et IT

Les professionnels de l'audiovisuel comprennent les exigences audio, tandis que les équipes informatiques gèrent les politiques du réseau. Planifiez des séances de planification conjointes pour s'aligner sur les valeurs DSCP, les affectations VLAN et les règles de sécurité. Encouragez l'IT à activer les fonctionnalités QoS qui sont parfois désactivées par défaut, comme l'insonorisation IGMP et le contrôle des tempêtes. Fournissez à l'IT une liste claire des valeurs DSCP et des portées de port UDP requises (p. ex. 5004-5005 pour RTP, 319-320 pour PTP) pour inclure dans les configurations pare-feu et ACL.

Défis communs et dépannage

Perte de paquets et abandons

Si vous avez des abandons audio, vérifiez d'abord la perte de paquets au point de départ. Utilisez les statistiques intégrées de l'appareil ou un analyseur RTP. Les causes communes comprennent:

  • Interrupteurs ne faisant pas confiance aux marques DSCP (traiter l'EF comme le meilleur effort).
  • Congestion de la file d'attente en raison d'inondations multicast excessives (fix en permettant l'inondation IGMP).
  • Bande passante insuffisante sur les liaisons montantes (vérifier à l'aide de compteurs d'utilisation de port).
  • Câblage défectueux ou mauvais modules SFP (vérifiez les erreurs CRC).

Questions de jitter et de timing

Les symptômes comprennent les clics, la distorsion ou la dérive de synchronisation. Vérifiez la stabilité de l'horloge PTP en mesurant le décalage et le jitter sur les périphériques esclaves. Corrections possibles : réduire la latence des commutateurs en permettant la commutation par coupure (si elle est prise en charge), en augmentant les intervalles d'annonce PTP ou en ajoutant des horloges limites pour isoler les domaines de l'horloge.

Congestion de la largeur de bande

Lorsque le trafic audio total dépasse la capacité de liaison, même les paquets hautement prioritaires peuvent être supprimés. Surfournir votre réseau : utilisez 1 Gbps ou 10 Gbps pour les connexions de base et limitez le nombre de flux audio par segment. Par exemple, à 48 kHz/24-bit, 512 canaux (par paires de stéréo) utilisent environ 1,4 Gbps. Une liaison de 1 Gbps peut gérer environ 350 canaux stéréo, laissant de la place pour des frais généraux. Utilisez l'agrégation de liens pour augmenter la bande passante par chemin.

Applications et scénarios du monde réel

Dans une grande installation de diffusion, plusieurs studios partagent un réseau unique avec des dizaines de sources et de destinations AES67. En mettant en œuvre un VLAN audio dédié, en marquant tous les paquets AES67 avec DSCP EF, et en configurant une file d'attente prioritaire stricte sur tous les commutateurs, l'installation peut maintenir une latence inférieure à milliseconde même si les transferts de fichiers et le trafic web sont actifs sur des VLAN séparés.

Un lieu de musique en direct AES67 pour les récepteurs de microphone sans fil, les consoles de mixage et les boîtes de scène bénéficie de l'inspection IGMP pour limiter le trafic multicast aux malles nécessaires. Avec QoS approprié, le système atteint la qualité audio cohérente même lors des émissions à la vente avec une charge d'appareil mobile lourde dans le public.

Les installations AV d'entreprise intègrent souvent AES67 avec les appareils Dante et RAVENNA. Un défi commun est que certains appareils non AES67 marquent des paquets avec différentes valeurs DSCP (par exemple, Dante utilise CS6). Dans ces environnements mixtes, créez plusieurs files d'attente prioritaires : une pour EF (AES67 audio), une pour CS6 (Dante audio), et assurez-vous qu'ils sont tous deux plus élevés que le meilleur effort. Certains intégrateurs préfèrent re-marquer tous les paquets audio à EF pour plus de simplicité.

Conclusion

La qualité de vie dans les environnements AES67 n'est pas une configuration ponctuelle, mais une pratique permanente de conception de réseau, de configuration des appareils, de surveillance et de collaboration d'équipe. En comprenant les fondements techniques – marquage DSCP, segmentation VLAN, gestion de la bande passante et calendrier PTP – et en mettant en œuvre les stratégies décrites ci-dessus, les professionnels de l'audio peuvent atteindre les performances peu latences et sans glissades que promet AES67.