Comprendre la latence et le jitter dans AES67

AES67 définit le transport d'audio numérique de haute qualité sur des réseaux IP en utilisant RTP (Real-time Transport Protocol). Deux paramètres de performance critiques – latence et jitter – déterminent si le système répond aux exigences de l'audio en temps réel. Latence est le temps total de la conversion analogique à numérique à la source à la conversion numérique à analogique à la destination. Jitter décrit la variabilité des temps d'arrivée des paquets par rapport à l'horloge attendue.

Latence : le budget de retard de bout en bout

Pour le renforcement sonore en direct, la latence aller-retour doit rester inférieure à 10 millisecondes (ms) pour éviter l'écho perceptible. Les applications de radiodiffusion nécessitent souvent des cibles de 1 à 5 ms. Chaque composant contribue : les commutateurs réseau introduisent des retards de stockage et de progression, les interfaces audio ajoutent des latences tamponnantes et les codecs (si utilisés) ajoutent un retard algorithmique. Comprendre ces contributions est la première étape vers l'optimisation. Un flux AES67 typique à 48 kHz avec un temps de paquet de 1 ms a une latence de base d'environ 1 ms plus un transit réseau et des retards tampons.

Jitter: Écart de temps dans les arrivées de paquets

Dans un réseau idéal, les paquets arrivent à un intervalle constant — tous les 125 μs pour un temps de paquet de 125 μs. Les réseaux réels introduisent la variance due à la file d'attente, au trafic éclate, à la discordance du tissu de commutation et à la dérive de l'horloge. Le tampon de jeu du récepteur est soit sous-courant (silence ou clics) soit sur-courant (glitches). Les récepteurs AES67 utilisent des tampons de délitage pour lisser les variations, mais un jitter excessif force le tampon à croître, augmentant la latence. Un réseau AES67 bien optimisé maintient le jitter en dessous de 1 ms de pointe à haut; les installations principales atteignent 100 à 300 μs. La tolérance des jitter dépend de la taille du tampon : un tampon de 1 ms absorbe le jitter jusqu'à ~0,5 ms, tandis qu'un tampon de 3 ms gère jusqu'à ~2 ms de jitter.

Conception de réseau pour la performance déterministe

Le réseau est le support commun pour tous les flux AES67. Les choix d'infrastructure les plus difficiles sont la source de latence et de jitter. Chaque élément – câbles, commutateurs, routage et services – doit être sélectionné et configuré pour une performance déterministe.

Interrupteurs gérés et qualité du service (QoS)

Les commutateurs non gérés ne peuvent pas prioriser le trafic AES67, ce qui entraîne une congestion et un jeu de signaux. Déployer les commutateurs gérés qui prennent en charge l'IEEE 802.1p (marquage prioritaire) et DiffServ (point de code des services différenciés). Affecter le trafic AES67 RTP à la file d'attente d'évacuation la plus élevée (rue 7) et utiliser un calendrier de priorité strict.

  • Désactiver Ethernet (EEE) à haut rendement énergétique parce que ses modes d'économie d'énergie ajoutent une variance de latence.
  • Activer le contrôle de flux seulement si tous les paramètres le supportent; les cadres de pause peuvent introduire le retard et doivent être testés avec soin.
  • Régler les tailles de tampons de commutateurs selon les recommandations du fabricant pour l'audio. Certains commutateurs permettent de régler l'allocation de tampons par port; réserver suffisamment de tampons pour les ports audio.

Pour les déploiements à grande échelle, utilisez des algorithmes de planification comme Weighted Strict Priority (WSP) ou Deficit Weighted Round Robin (DWRR) avec des files d'attentes à faible latence.

VLAN et isolation routière

Séparer le trafic AES67 sur un VLAN dédié empêche la concurrence des émissions informatiques, des transferts de fichiers et des flux vidéo. Un VLAN unique avec une QoS stricte fonctionne pour de nombreuses configurations, mais pour de grands déploiements créent un VLAN Audio dédié avec son propre sous-net. Configurer l'insonorisation IGMP pour limiter le trafic multicast à seulement les ports qui en ont besoin – autrement, les inondations multicast inutiles causent des jitters.

Désactiver le protocole d'arbre d'éblouissement (STP) sur les ports audio si la topologie est simple. Si STP est nécessaire (liens redondants), utilisez Rapid Spanning Tree (RSTP) avec des ajustements prioritaires pour assurer une convergence rapide sans impact sur les flux. Activez PortFast (Cisco) ou Edge Port (standard) sur tous les ports d'accès connectés aux paramètres audio.

Désactivez également les services inutiles sur le VLAN audio : DHCP, DNS, NetBIOS, LLDP (si ce n'est pas nécessaire) et tout autre protocole générateur de radiodiffusion. Chaque paquet de radiodiffusion consomme de l'espace tampon et augmente la variance de jitter.

Cabine et couche physique

Pour les parcours de plus de 100 mètres, utiliser des connexions à fibre optique avec des émetteurs-récepteurs SFP; la fibre élimine les interférences électriques et fournit une latence constante. Assurez-vous que tous les liens fonctionnent à la vitesse la plus élevée courante (1 Gbps ou 10 Gbps) pour minimiser le délai de sérialisation. Un lien de 10 Gbps sérialise un paquet de 1500 octets en 1,2 μs, contre 12 μs sur 1 Gbps. Éviter les problèmes de négociation automatique en fixant la vitesse et le duplex sur les liens critiques.

Changer les critères de sélection pour AoIP

Tous les commutateurs gérés ne sont pas égaux.

  • Interrupteur à faible latence (transfert par la suite préféré pour l'audio, mais de nombreux commutateurs gérés utilisent le stockage et l'avant; s'assurer que la latence de la transmission est inférieure à 5 μs par houblon).
  • Horodatage matériel pour PTP (Support de l'horloge fixe ou transparente).
  • Capacité multicast suffisante (p. ex. groupes multicasts 4K+) et IRMG.
  • tampon d'évacuation configurable par port (au moins 512 KB par port pour gérer les rafales).

Les fournisseurs comme Cisco (Catalyste 9300), Aruba (série CX), Netgear (série M4300 pour AV) et Luminex (spécifiquement pour AoIP) offrent des modèles appropriés. Guide de conception du réseau Audinate Dante pour les recommandations relatives aux commutateurs de réseau qui s'appliquent également à AES67.

Stratégies avancées de gestion des tampons et de pliage

Les appareils modernes conformes à l'AES67 permettent une configuration étendue des tailles de tampons et des temps de paquets. Les réglages incorrects sont une cause principale de performances sous-optimales.

Taille de tampon

Le tampon de jeu (dejitter) absorbe le jitter mais ajoute de la latence. Le but est le plus petit tampon qui empêche de façon fiable les infiltrations. Commencez par 1 ms (environ 48 échantillons à 48 kHz). Augmentez graduellement tout en surveillant les journaux d'erreurs jusqu'à ce que le nombre d'erreurs tombe à zéro. Pour les applications critiques pour la mission, 2 à 3 ms fournissent une marge de sécurité.

Envisager d'utiliser l'adaptation dynamique du tampon si elle est prise en charge. Certaines implémentations AES67 ajustent la profondeur du tampon en fonction de la valeur mesurée en temps réel.

Sélection du temps de conditionnement : 125 μs vs 1 ms vs 4 ms

AES67 prend en charge les temps de paquets de 125 μs à 8 ms. Les temps de paquets plus courts réduisent la latence mais augmentent le coût du réseau et la charge du processeur. Pour le son en direct, les paquets de 1 ms ou 250 μs sont courants. Des temps de paquets plus longs (4-8 ms) peuvent être utilisés pour la lecture en temps non réel.

  • 125 μs: Latence ~125 μs plus délai réseau. Overhead: 150+% (en-tête RTP + charge utile). Nécessite des performances de commutateur élevées pour gérer de nombreux petits paquets.
  • 1 ms: Latence ~1 ms plus réseau.
  • 4 ms: Latence ~4 ms plus réseau. Overhead: ~5%. Acceptable pour la lecture mais pas pour live.

Assurez-vous que tous les appareils dans un flux conviennent du même temps de paquet. Certains convertisseurs permettent la négociation automatique; vérifiez manuellement pendant la mise en service.

Correction d'erreur de renvoi (FEC) et redondance

AES67 ne prévoit pas de CFE, mais certaines implémentations l'ajoutent (p. ex. redondance RTP ou SMPTE 2022-7). FEC peut récupérer des paquets perdus au prix de largeur de bande et de latence supplémentaires (1-2 ms). Utilisez CFE uniquement sur des réseaux peu fiables; pour les réseaux contrôlés, comptez sur QoS et le réglage tampon.

Délai de précision avec PTP

L'AES67 découple la diffusion de la synchronisation à l'échelle du système à travers une horloge dédiée, dérivée du protocole de précision du temps (PTP).

PTP Sélection et configuration Grandmaster

Utilisez un grandmaster d'heure d'amplificateur matériel (p. ex., commutateur PTP dédié ou interface audio). Configurez tous les paramètres comme des horloges ordinaires. Le numéro de domaine PTP doit être cohérent (par défaut 0 pour AES67). Définissez l'intervalle de synchronisation PTP à 1 seconde (logSyncInterval = 0) et annoncez l'intervalle à 2 secondes. Pour les réseaux avec plus de 10 houblons, utilisez des horloges limites pour réduire l'accumulation de jitters.

Paramètres clés de PTP :

  • Classe d'horloge : Définissez la classe d'horloge grand-maître à 6 (référence primaire), les paramètres à 248 (par défaut).
  • Précision de l'horloge: Objectif de précision de 0,001 μs (échelle 0x21).
  • Priorité1 et Priorité2: Définir des valeurs plus basses pour le grand maître désigné pour assurer une sélection cohérente.

Utilisez un oscillateur discipliné GNSS pour le grand maître. Les références Rubidium ou OXO améliorent encore la stabilité.

Horloges de limite et horloges transparentes

Dans les grands réseaux, les messages PTP traversent plusieurs commutateurs. Les horloges de bordure (BC) ou les horloges transparentes (TC) compensent les retards de commutation. Les BC agissent comme des commutateurs PTP-aware qui régénèrent les messages de synchronisation; ils nécessitent un chronométrage matériel. Les TC modifient les messages PTP pour corriger le temps de résidence. Pour AES67, le profil Audio Video Bridging (AVB) utilise les TC, tandis que le profil standard AES67 repose souvent sur les BC.

Outils de surveillance PTP pour vérifier le décalage et le décalage.

Domaines de l'horloge et verrouillage de l'horloge d'échantillon

Les appareils AES67 peuvent utiliser différents domaines d'horloge : l'horloge échantillon (pour la conversion audio) et l'horloge réseau (pour PTP). Idéalement, les deux dérivent de la même horloge maître pour éliminer la dérive. De nombreux appareils professionnels permettent de verrouiller l'horloge échantillon à PTP en utilisant une PLL interne. Vérifiez que le grand maître PTP est stable et que les paramètres utilisent la même source d'horloge. En cas de défaillance grandmaster, la défectuosité automatique d'un autre maître doit être configurée, mais notez que la défectuosité provoque une brève pointe de jitter.

Testez la défectuosité lors de la mise en service.

Surveillance et dépannage proactif

Même avec une conception soignée, les réseaux du monde réel introduisent des variables. La surveillance continue est essentielle pour maintenir une faible latence et des jitters au fil du temps.

Outils d'analyse de réseau

Utilisez un logiciel d'analyse AoIP dédié pour mesurer la jitter, la perte de paquets et la latence. Pour AES67, des outils comme Dante Controller (montre la latence et les erreurs), Filière Avec l'analyse RTP, et des testeurs spécialisés (p. ex. Audio Precision APx500, RME Digicheck) fournissent une vue d'ensemble approfondie. Capturez les paquets RTP et examinez les horodatages et les numéros de séquence. Le jitter peut être calculé selon la définition RTCP (jitter inter-arrivée).

Mesures supplémentaires à surveiller:

  • PTP offset (devrait être < 1 µs).
  • Délai de chemin PTP (devrait être < 100 µs for local networks).
  • Interrupteur utilisation du processeur (une utilisation élevée peut causer des retards dans le calendrier).
  • Décharges de file d'attente de port (indiquer les dépassements de tampon).

Mises à jour du logiciel et du firmware

Les fabricants publient fréquemment des améliorations aux profils PTP, aux algorithmes tampons et à la gestion de QoS. Documenter les versions du firmware et maintenir un changement de journal. Un seul commutateur obsolète peut dégrader tout le réseau. Tester les mises à jour du firmware dans un environnement de mise en scène avant la production.

Pièges et correctifs communs

  • Vitesses de liaison mixtes: Un port de commutation de 100 Mbps dans un réseau Gigabit crée un goulot d'étranglement qui augmente les jitters.
  • Mises à jour de l'arbre d'évasement : Si STP reconverge, les flux audio peuvent tomber. Utilisez PortFast ou les ports de bord pour tous les appareils audio.
  • Services inutiles: Désactiver les services DHCP, DNS et autres services IP sur VLANs audio seulement pour réduire le bruit de diffusion.
  • Dérivation de l'horloge : Vérifiez que le grand maître est verrouillé à une référence externe (GNSS ou horloge de mot) et que tous les paramètres utilisent la même source d'horloge.
  • Attribution de tampons de commutation & #160;: Certains commutateurs partagent des tampons entre les ports; le trafic lourd sur un port peut affecter d'autres. Utilisez la réservation tampon basée sur le port si disponible.

Conclusion

En utilisant des commutateurs gérés avec QoS, en isolant le trafic audio sur un VLAN dédié, en harmonisant les tailles de tampon et en mettant en œuvre une synchronisation PTP précise, les ingénieurs peuvent obtenir une latence et un jitter sous-millisecondes adaptés aux applications les plus exigeantes en direct et en diffusion. Norme AES67 de la Société Audio Engineering, les IEEE 1588 Ressources du protocole de temps de précision du NIST, et les guides de configuration QoS réseau de votre fournisseur de commutateurs. L'effort investi dans la conception et les tests rapporte des dividendes dans la transmission audio fiable et de haute qualité.