Introduction : Pourquoi le Protocole Audio compte dans la radiodiffusion moderne

Dans l'installation de radiodiffusion actuelle, l'audio n'est plus un simple signal analogique qui traverse des lignes de cuivre dédiées. C'est un flux numérique traversant des réseaux Ethernet standard, et le protocole qui régit son transport est aussi fondamental que l'acoustique de votre salle de contrôle. Le mauvais protocole peut introduire une latence inacceptable, causer des conflits d'horlogerie, vous verrouiller dans un seul fournisseur, ou nécessiter une refonte complète du réseau lorsque vous avez besoin d'échelle.

Cette décision n'est pas seulement technique, elle est stratégique. Que vous construisiez une station de terrain vert, que vous rénoviez une usine existante ou que vous planifiiez une migration progressive à partir d'un système MADI ou analogique, votre choix de protocole affectera chaque pièce d'équipement que vous achetez, chaque commutateur réseau que vous configurez, et chaque ingénieur que vous formez. Les radiodiffuseurs font face aujourd'hui à une pression croissante pour soutenir la production à distance, les flux de travail hybrides et la vidéo UHD sur IP. Le protocole audio que vous sélectionnez doit s'aligner avec ces objectifs opérationnels plus larges.

Comprendre les protocoles audio-over-IP (AoIP)

Les protocoles audio sont des méthodes normalisées pour l'encodage, le paquetage et le transport de réseaux audio numériques sur protocole Internet (IP). Ils définissent la façon dont les échantillons audio sont formatés, comment le timing est maintenu (horlogerie), comment les appareils se découvrent et comment les flux sont acheminés.

Les installations de radiodiffusion ont des exigences uniques : faible latence déterministe, fiabilité élevée, support pour le comptage des grands canaux et interopérabilité avec les systèmes de production et de transmission. AES67, Ravenne, Danteet Fils vivants. Chacun est construit sur des principes similaires (RTP, PTP) mais diffère dans la mise en œuvre, l'écosystème, et les caractéristiques. Comprendre ces différences est essentiel parce que votre installation peut avoir besoin de soutenir plusieurs protocoles simultanément pendant une migration ou dans un environnement multivendeur.

Au-delà des protocoles de base, de nombreuses installations rencontrent également MADI Bien que MADI soit un format série point à point plutôt qu'un protocole basé sur l'IP, il demeure courant pour connecter des consoles, des routeurs et des appareils d'enregistrement plus anciens. La planification d'un chemin de conversion de MADI à un protocole AoIP natif est une considération fréquente lors des mises à niveau de l'installation.

AES67: La norme d'interopérabilité universelle

AES67 est une norme ouverte publiée par l'Audio Engineering Society (AES). Ce n'est pas une pile de protocole complète mais un ensemble de spécifications qui assurent l'interopérabilité entre différents systèmes AoIP. Il définit le support obligatoire pour l'audio PCM, les taux d'échantillonnage spécifiques (48 kHz, 96 kHz) et l'utilisation du protocole de précision (PTPv2) pour la synchronisation.

Pour les installations qui ont déjà un mélange de Dante, Ravenna ou Livewire, AES67 agit comme un pont. C'est aussi la base pour SMPTE ST 2110-30, la norme pour les médias professionnels de diffusion sur IP. Cependant, AES67 seul ne fournit pas la découverte, la gestion de connexion, ou la configuration de routage multicasts — ceux-ci sont gérés par le protocole natif de chaque appareil. Cela signifie que, bien que AES67 garantit la compatibilité de base du transport, l'expérience utilisateur nécessite souvent une configuration logicielle ou manuelle supplémentaire.

La norme AES67 a évolué. Révision AES67-2022 L'AES67 est de plus en plus viable en tant que protocole primaire pour les installations plus grandes, et non seulement un outil de transition. Pour une installation qui valorise la flexibilité à long terme et l'indépendance des fournisseurs, la stratégie de transport commune est solide.

Principaux points forts: Open standard, neutralisé par les fournisseurs, anti-disponibilité pour les écosystèmes de la propriété intellectuelle, aucun droit de licence par port. Considérations: Aucune découverte d'appareil intégrée; nécessite une planification minutieuse du réseau pour le PTP et la multidiffusion; peut nécessiter un logiciel de gestion supplémentaire.

En savoir plus sur le Page sur les normes AES- Oui.

Dante : Le chef de file de la facilité d'utilisation

Dante, développé par Audinate, est le protocole AoIP le plus largement déployé dans le monde pro-audio et de radiodiffusion. Son principal avantage est la simplicité : les appareils compatibles Dante se découvrent automatiquement sur le réseau et le routage audio est géré par une application logiciel libre (Dante Controller). La latence est configurable de 0,25 ms à 10 ms, ce qui le rend adapté aux flux micro vivants et aux moniteurs de studio.

Dante supporte jusqu'à 1024 x 1024 canaux audio par appareil avec des voies réseau redondantes (Dante Redundant), et son horlogerie est très robuste. L'écosystème est énorme, avec des centaines de fabricants offrant des cartes Dante et des interfaces intégrées. Pour les installations de radiodiffusion, Dante est souvent choisi lorsque la principale exigence est un déploiement rapide et une grande base de produits existante. Cependant, il y a des nuances: le système standard Dante utilise un sous-net unique et ne fait pas router l'audio nativement sur les VLAN sans l'ajout de Dante Domain Manager, qui introduit les coûts par abonnement.

Pour les installations intégrant des flux de travail vidéo-sur-IP, Dante offre le Dante AVIO Audinate participe également à l'écosystème SMPTE ST 2110, bien que le protocole natif de Dante diffère du modèle AES67/RTP utilisé dans ST 2110. Cela signifie que la liaison entre Dante et un environnement ST 2110 complet peut nécessiter des étapes de conversion ou du matériel supplémentaires.

Principaux points forts: Facilité d'utilisation, découverte automatique, large écosystème de produits, faible latence, horloge robuste. Considérations: La licence propriétaire ajoute des coûts par appareil (généralement de 50 $ à 150 $ par paramètre); non conforme nativement à la norme SMPTE ST 2110 sans pont supplémentaire; limitations mono-sous-réseau sans gestionnaire de domaine.

Ravenne: Haute performance pour les grandes installations

Ravenna est une technologie ouverte développée à l'origine par ALC Network (qui fait désormais partie de l'alliance AES67-Ravenna). Elle met l'accent sur la densité de canaux, la latence sous-milisec et la redondance. Ravenna utilise la norme IEEE 1588 PTPv2 pour la synchronisation et le RTP pour le transport, et elle est entièrement compatible par défaut avec AES67. Elle est largement adoptée dans les consoles de radiodiffusion, matrices de routage et systèmes d'intercom de fabricants comme Layo, DirectOut, Neumann et Merging Technologies.

La force de Ravenne réside dans sa capacité à gérer des installations à grande échelle avec des centaines de flux simultanés tout en maintenant un calendrier déterministe. Il prend en charge à la fois unicast et multicast, et offre des fonctionnalités de redondance réseau avancées comme un basculement sans soudure en utilisant RSTP ou l'agrégation de liens propriétaires. Le protocole supporte également une large gamme de taux d'échantillonnage (jusqu'à 192 kHz) et de profondeurs de bits, ce qui le rend adapté pour des applications audio haute résolution au-delà de la diffusion standard.

Une considération pratique est que les déploiements Ravenne nécessitent généralement plus d'expertise réseau que Dante. Gestionnaire Web Ravenna Simplifier la découverte et la configuration, la configuration initiale, notamment pour le routage multicast et la hiérarchie PTP, exige une planification minutieuse. Cependant, une fois configurés, les systèmes Ravenna sont extrêmement stables et évolutives.

Principaux points forts: Nombre de chaînes élevées, excellent chronométrage, standard ouvert (sans royalté), solide support du fournisseur de radiodiffusion, alignement Natif ST 2110. Considérations: Courbe d'apprentissage légèrement plus raide que Dante; la gestion de la découverte et de la connexion est plus manuelle; nécessite des commutateurs gérés de qualité avec le support PTP.

Livewire: Streamlined pour la radio et la radio

Livewire, développé par Telos Alliance, a été l'un des premiers systèmes AoIP spécifiquement conçus pour la radio de radiodiffusion. Il utilise le protocole Livewire+, qui est construit sur la même fondation RTP/PTP que AES67. Livewire est connu pour son intégration étroite avec les systèmes téléphoniques Telos, les consoles Axia et d'autres périphériques de radiodiffusion. Il offre une configuration automatique, GPIO intégré sur IP, et une convention de nommage simple pour les canaux audio qui s'aligne sur la terminologie du flux de travail de radiodiffusion (par exemple, "Studio 1 Mic 1").

Livewire est particulièrement populaire dans les stations de radio et les petites installations de télévision où l'écosystème des équipements Telos/Axia est déjà en service. Les dernières implémentations Livewire+ sont conformes à AES67, ce qui leur permet de parler avec d'autres protocoles sur le réseau. Cela signifie qu'une installation basée sur Livewire peut intégrer des appareils Dante via AES67 si nécessaire, bien que la configuration puisse nécessiter des étapes manuelles.

Cependant, l'écosystème des appareils hors du monde Telos est plus limité que Dante ou Ravenna. Si vous choisissez Livewire, vous vous engagez stratégiquement dans l'écosystème Telos Alliance pour les consoles, les systèmes téléphoniques et les périphériques. Cela peut être un avantage si vous utilisez déjà Telos engrenage, mais il limite la flexibilité si vous souhaitez intégrer ultérieurement des appareils tiers qui ne disposent pas de soutien natif Livewire. Livewire est le mieux adapté aux installations où l'intégration du flux de travail de radiodiffusion et la simplicité sont les priorités principales, et où l'ensemble de la chaîne audio peut être standardisé autour des produits Telos.

Principaux points forts: Configuration simple, outils intégrés de flux de travail de radiodiffusion, GPIO intégré sur IP, conformité AES67 dans les versions récentes. Considérations: Idéal pour les équipements Telos/Axia; moins de diversité des fournisseurs; plus petit écosystème pour les appareils tiers.

Facteurs décisionnels essentiels

Au-delà des fonctions protocolaires, votre choix doit s'aligner sur la réalité opérationnelle de votre installation. Voici les facteurs qui comptent le plus dans un contexte de diffusion.

Compatibilité et interopérabilité

Si votre protocole choisi n'est pas compatible avec AES67, vous pouvez faire face à des passerelles ou des convertisseurs de format coûteux. Recherchez des appareils qui supportent nativement AES67 ou SMPTE ST 2110-30. Pensez également à l'intégration future avec vidéo-over-IP (SMPTE ST 2110), qui nécessite généralement AES67 pour l'essence audio. Par exemple, si vous prévoyez de vous connecter à un routeur centralisé qui gère à la fois la vidéo et l'audio, vous devez vous assurer que votre protocole audio utilise le même domaine PTP que votre infrastructure vidéo pour éviter les erreurs d'horloge.

Dans les environnements multiprotocoles, planifier une stratégie de passerelle. Certains fabricants offrent des ponts matériels (par exemple, la série Converter de DirectOut) qui traduisent en temps réel entre Dante, Ravenna, MADI et AES67. Des solutions basées sur le logiciel existent également, mais elles peuvent introduire des latences ou des frais généraux de traitement. La clé est d'évaluer non seulement si deux protocoles peuvent coexister, mais comment ils interagissent de façon propre et fiable sous des charges de diffusion.

Exigences de latence

Pour la diffusion en direct, la latence inférieure à 1 milliseconde est souvent nécessaire pour la surveillance du retour, de l'interphone et du microphone. Dante et Ravenna peuvent atteindre 125 microsecondes aux réglages tampons les plus bas, tandis que les implémentations AES67 fonctionnent généralement à 1 ms ou plus. Testez la latence réelle avec votre matériel réseau. Considérez également la latence cumulative sur plusieurs houblons : si vous reliez des installations sur un WAN, vous devrez peut-être tenir compte des retards de propagation du réseau.

Certains protocoles vous permettent de contrer la latence contre la robustesse du réseau. Un tampon plus petit réduit la latence mais augmente le risque d'abandon du réseau. Dans un réseau bien conçu avec des commutateurs gérés et des QoS dédiés, vous pouvez opérer en toute sécurité aux paramètres de tampon les plus bas. Si votre infrastructure réseau est moins contrôlée ou comprend des liaisons sans fil, un réglage tampon légèrement plus élevé (par exemple, 2 ms) peut être plus sûr.

Infrastructure réseau et bande passante

Broadcast AoIP utilise généralement des commutateurs multicasts pour une distribution efficace. Cela nécessite un snooping IGMP activé sur vos commutateurs Ethernet gérés, ainsi qu'une horloge limite PTP robuste ou une hiérarchie d'horloge ordinaire. Les commutateurs non gérés ne conviennent pas. Bandwidth est rarement un problème : un seul canal stéréo non compressé de 48 kHz/24-bit utilise environ 2,3 Mbps. Même un système 128 canaux est bien inférieur à 1 Gbps.

Cependant, vous devez prévoir des réseaux redondants (primaire et secondaire) pour survivre à une panne de commutateur sans perdre l'audio. Cela signifie doubler votre infrastructure de commutation et le câblage, ce qui peut être un coût important dans les grandes installations.

Les commutateurs de réseau pour AoIP devraient avoir des oscillateurs d'horloge de haute qualité pour supporter la fonctionnalité d'horloge transparente ou de l'horloge limite PTP. Tous les commutateurs gérés ne sont pas égaux à cet égard. Les commutateurs de fabricants comme Cisco, Arista, Netgear et Luminex offrent des modèles spécifiques certifiés pour l'utilisation d'AoIP. Vérifiez la liste de commutateurs recommandée par le fabricant pour votre protocole choisi.

Évoluabilité et croissance future

Choisissez un protocole qui s'échelle à la fois en nombre de canaux et en portée géographique. Les systèmes basés sur Ravenne et AES67 peuvent facilement atteindre des milliers de canaux à travers plusieurs bâtiments avec une distribution PTP appropriée. Dante balance à 1024 canaux par appareil mais peut être limité par le concept de domaine unique; Dante Domain Manager permet une échelle à travers les VLAN et les sites mais ajoute des coûts. Livewire est plus adapté à une installation ou un campus de taille modérée.

Un protocole largement utilisé dans votre région ou par vos ingénieurs du personnel peut être plus facile à entretenir et à résoudre que d'autres. Facteur de la disponibilité de la formation, des programmes de certification et du soutien de tiers. Par exemple, Dante offre des niveaux de certification de l'associé à l'expert, qui peuvent être utiles pour le perfectionnement du personnel.

Coût de la propriété

Les frais de licence sont inclus dans le coût du matériel. Dante a une redevance par port qui ajoute souvent de 50 $ à 150 $ par point d'arrêt. Ravenne et AES67 sont exempts de redevances, de sorte que leur matériel peut être moins cher, mais vous payez pour les commutateurs de réseau avancés et éventuellement pour les outils de gestion de logiciels. Facteur dans les coûts de formation: les ingénieurs familiers avec un protocole peuvent avoir besoin de temps pour en apprendre un autre.

Si votre installation exige la conformité SMPTE ST 2110, vous devrez peut-être payer pour les tests de conformité officiels sur vos appareils et votre réseau. Ceci est plus courant dans les grands centres de radiodiffusion et les centres d'exploitation du réseau.

Considérations pratiques de conception de réseau

La mise en œuvre d'AoIP dans une installation de radiodiffusion n'est pas un exercice de plug-and-play. Vous devez concevoir votre réseau pour répondre aux exigences spécifiques du protocole que vous choisissez.

Protocole de précision et horlogerie

Tous les protocoles AoIP reposent sur PTPv2 (IEEE 1588-2008) pour synchroniser les horloges d'échantillonnage sur tous les appareils. Une horloge grand-maître PTP (souvent GPS-disciplinée externe) fournit une référence de temps maître. Pour les installations avec vidéo, vous pouvez avoir besoin de verrouiller PTP audio à la référence vidéo (comme le genlock) pour éviter la dérive pendant la production. Assurez-vous que les commutateurs réseau sont PTP-aware (horloges transparentes ou horloges limites) pour maintenir la précision sous-microseconde sur de nombreux houblons. Dans une grande installation avec plusieurs niveaux de commutation, planifiez votre hiérarchie PTP avec soin: chaque commutateur devrait être configuré comme une horloge limite si possible, plutôt que de compter sur le mode d'horloge transparente de bout en bout, qui devient inexact sur de nombreux houblons.

Certaines installations choisissent de lancer des domaines PTP séparés pour l'audio et la vidéo pour isoler les problèmes d'horlogerie. Cependant, cela ajoute de la complexité et nécessite une gestion prudente aux frontières. Une approche plus simple est d'utiliser une seule horloge grandmaster avec un profil PTP qui prend en charge à la fois l'audio (profil IEEE 1588 pour AES67) et la vidéo (SMPTE ST 2059-2).

Qualité du service (QoS)

Configurez le marquage DSCP sur les commutateurs : typiquement DSCP 46 (Expedited Forwarding) pour les flux audio. Définissez des files d'attentes strictement prioritaires et limitez l'utilisation de la bande passante pour éviter la congestion. Testez votre réseau avec un générateur de paquets avant de connecter le matériel audio réel. Dans un réseau convergent qui transporte des données audio, vidéo et données, vous aurez peut-être besoin de plusieurs classes de trafic : voix/audio (la priorité la plus élevée), vidéo en streaming (medium), données de contrôle (moyen-bas) et données de meilleur effort (la plus basse).

Chaque flux audio utilise une adresse MAC multicast, et les commutateurs doivent apprendre et les transmettre efficacement. Activer l'inversion IGMP et configurer un questionnaire pour chaque VLAN transportant de l'audio multicast. Sans configuration IGMP correcte, les commutateurs peuvent inonder le trafic multicast vers tous les ports, gaspiller la bande passante et causer la perte de paquets.

Redondance et échec

La diffusion ne peut pas se permettre de temps d'arrêt. Implémenter un réseau secondaire parallèle (interrupteurs et câbles séparés) pour le protocole audio primaire. < 4 ms). Document your network topology and test failover scenarios regularly. In practice, many facilities run primary and secondary networks in an active/standby configuration, with the secondary network fully isolated and tested weekly. Some advanced setups use link aggregation or even LAG with active/active traffic, but this requires careful validation of switch convergence times.

Chaque commutateur réseau devrait avoir deux alimentations connectées pour séparer les flux UPS. Considérez également les horloges PTP grandmaster redondantes en configuration de veille à chaud. Les horloges grandmaster devraient être synchronisées via GPS ou une autre source de temps commune pour assurer une transmission transparente en cas de défaillance du primaire.

Proofing futur avec SMPTE ST 2110 et AES67

La tendance de la diffusion est vers une production IP complète, où les données, vidéo et audio sont toutes transmises sur le même réseau en utilisant les normes SMPTE ST 2110. L'audio ST 2110 est défini par ST 2110-30 (PCM audio, essentiellement AES67) et ST 2110-31 (AES3-transport). Si vous prévoyez de passer à la vidéo IP dans les prochaines années, sélectionner un protocole audio conforme à ST 2110-30 évitera une ré-architecture majeure. Ravenna et Dante (avec Dante AVIO ou Dante Domain Manager) peuvent s'intégrer, mais Ravenna est plus directement alignée sur ST 2110 car elle utilise les mêmes normes sous-jacentes et les mêmes profils PTP.

Pour les installations radio uniquement, ST 2110 peut être moins pertinent, mais AES67 reste l'épine dorsale d'interopérabilité. La révision AES67-2022 a ajouté le support pour 96 kHz et des profils PTP améliorés, le rendant encore plus robuste. Même si vous ne passez pas à la vidéo-over-IP aujourd'hui, le choix d'un protocole compatible avec AES67 préserve vos options pour la collaboration future avec les équipes de production vidéo, les camions distants et les workflows basés sur le cloud.

Plusieurs fournisseurs proposent maintenant des routeurs audio virtualisés et des moteurs de traitement qui fonctionnent sur du matériel de serveur standard et se connectent à l'installation via AoIP. Ces systèmes comptent généralement sur AES67 ou ST 2110-30 pour l'interface avec le matériel physique. Si vous prévoyez de transférer un certain traitement (mélangage, routage, encodage) au cloud, assurez-vous que votre protocole audio choisi peut se rapprocher d'un environnement cloud avec une faible latence et un support pour le calendrier réseau sur le WAN.

Étude de cas : Choisir un protocole pour un service de nouvelles télévisées de taille moyenne

Considérez une installation avec 6 salles de contrôle, 4 studios et une salle de machine centrale. Ils prévoient de remplacer un ancien routeur analogique par AoIP. L'installation dispose déjà d'une console d'un fabricant supportant Ravenna (Lawo), mais utilise également des récepteurs micro sans fil avec sorties Dante. Après analyse, l'équipe d'ingénierie choisit Ravenna comme l'épine dorsale parce qu'elle est conforme à AES67 et permet aux appareils Dante de se connecter via la passerelle AES67. Ils installent une horloge grandmaster PTP et gèrent le routage multicast à travers un contrôleur logiciel central.

Le résultat est une infrastructure IP unique pour tous les audio, avec une salle pour ajouter 2110 vidéo à l'avenir.

La leçon clé de cette étude de cas est de choisir un protocole qui relie vos îles existantes plutôt que de forcer un écosystème à un seul vendor. L'équipe a investi dans une passerelle (DirectOut EXBOX.MD) pour convertir les flux Dante en AES67 pour le réseau Ravenna. Cela a ajouté un certain coût et complexité mais a préservé l'investissement existant en micro sans fil. Au fil du temps, les dispositifs Dante sont remplacés, l'équipe peut passer à Ravenna-native engrenage, simplifiant davantage l'architecture.

Cadre décisionnel étape par étape

  1. Vérifiez votre équipement existant. Énumérez chaque appareil audio, son support de protocole actuel et sa durée de vie prévue. Incluez les consoles, les récepteurs de microphone, les systèmes d'interphone, les matrices de routage et les appareils d'enregistrement.
  2. Définissez vos besoins de latence et de compte de canal. Pour un spectacle de conversation en direct, la latence inférieure à 1 ms est critique. Pour la lecture radio, 2 à 5 ms peuvent être acceptables. Comptez vos besoins actuels et futurs de canaux, en tenant compte de la croissance de nouveaux studios ou de nouvelles productions.
  3. Déterminez votre feuille de route pour l'intégration vidéo. Si vous prévoyez de passer à la vidéo IP, prioriser la compatibilité AES67/ST 2110. Si vous restez SDI pour les cinq prochaines années, le choix du protocole est moins limité, mais vous devriez quand même envisager l'interopérabilité avec les partenaires de production à distance qui peuvent utiliser IP.
  4. Évaluer votre état de préparation au réseau. Vos commutateurs peuvent-ils gérer PTP, IGMP et QoS? Avez-vous un budget pour un réseau redondant? Si votre infrastructure réseau vieillit, facteur dans le coût de mise à niveau vers des commutateurs gérés avec la capacité d'horloge limite PTP.
  5. Sélectionnez deux ou trois protocoles candidats. Testez-les dans un laboratoire avec un équipement représentatif avant de vous engager. Utilisez un plan de test qui mesure la latence, le jeu, la stabilité de l'horloge et le temps de basculement. Inclure au moins un scénario audio de production qui reflète votre flux de travail typique.
  6. Considérez les risques de verrouillage des fournisseurs. Préférez des standards ou des protocoles ouverts avec plusieurs fabricants. Si vous choisissez un protocole propriétaire, avez un chemin de migration documenté vers AES67 ou ST 2110 si nécessaire plus tard.
  7. Plan de formation et de soutien. Assurez-vous que votre équipe d'ingénierie peut maintenir le système choisi. Budget pour la formation des fabricants, les programmes de certification et les consultants externes si l'expertise interne est insuffisante.

Conclusion

Choisir le bon protocole audio pour votre installation de radiodiffusion est une décision multidimensionnelle qui équilibre les performances techniques, les équipements existants, la croissance future et le budget. Il n'y a pas de protocole universel « meilleur » ; plutôt, le meilleur choix est celui qui s'harmonise avec le workflow et la feuille de route spécifiques de votre installation. AES67 fournit la base pour l'interopérabilité de tous les systèmes, tandis que Dante offre la simplicité, Ravenna fournit des performances à haute densité de canaux, et Livewire s'intègre étroitement avec les consoles de radiodiffusion. Commencez par comprendre vos besoins de latence et d'évolutivité, puis évaluez les besoins de chaque écosystème et réseau de chaque protocole.

L'industrie de la radiodiffusion se dirige régulièrement vers la production IP intégrale, et les protocoles audio sont le fondement de cette transition. En faisant un choix stratégique éclairé aujourd'hui, vous positionnez votre installation pour s'adapter aux nouveaux flux de travail, aux nouveaux partenaires et aux nouvelles technologies sans retravailler coûteux.

Pour plus de détails, explorez la Écosystèmes de Ravenne et les Ressources techniques Audinate Dante. La suite de normes SMPTE ST 2110 est documentée à la Site Web du SMPTE. Pour une plongée plus profonde dans le calendrier PTP et la conception de réseau pour la diffusion, consulter le Norme IEEE 802.1AS- Oui.