Le transport de signaux audio numériques multiplexés n’est pas une nouveauté. Dans un premier temps, les liaisons étaient assurées en mode point à point, d’une machine à l’autre comme avec un bon vieux câble multipaires, comme le Madi ou l’AES50. Ensuite sont apparus des systèmes de transmission avec des topologies spécifiques en anneau (Optocore, Rocknet, Ethersound…) qui facilitaient le câblage en volant lors d’une prestation mais restaient éloignées des topologies en étoile des réseaux informatiques.
L’objectif est de profiter des infrastructures réseau existantes et de la réduction de coûts de la connectique utilisés à grande échelle par l’informatique. La distribution audio sur un câble Ethernet facilite aussi l’accès aux logiciels d’enregistrement audio sur ordinateur en supprimant la traditionnelle carte audio, sous réserve que les drivers spécifiques soient disponibles. Selon les protocoles proposés, des divergences apparaissent en fonction du niveau de la couche choisie dans le modèle OSI.
Les systèmes précurseurs comme CobraNet ou Ethersound, ou plus récents comme l’AVB, gèrent les échanges de données au niveau 2 de l’architecture OSI, ce qui implique que les équipements sont repérés au niveau Ethernet via leur adresse MAC. Les échanges restent alors limités au périmètre d’un sous-réseau sans aucune fonction de routage IP. D’autres systèmes comme Dante ou Ravenna ont choisi le niveau 3 et communiquent via une adresse IP. Grâce aux fonctions d’échange d’un routeur, des équipements situés sur des réseaux distincts sont capables de dialoguer dans des architectures plus larges.
Dante, un indéniable succès
Le protocole Dante a été lancé en 2006 par Audinate, une société créée en Australie par une équipe d’ingénieurs issus d’un laboratoire de recherches de Motorola. On y retrouve les objectifs initiaux de CobraNet et d’Ethersound, mais cette fois en s’appuyant sur une topologie en étoile et un transport en Gigabit Ethernet au lieu du 100 Mb/s initial. Dante assure le transport audio bidirectionnel à travers des switchs standards en mode UDP unicast ou multicast avec une latence inférieure à la milliseconde.
Audinate a conçu le protocole qu’elle propose sous forme de licences auprès des constructeurs d’équipements audio. La société fournit à la fois les circuits intégrés FGPA et les API logicielles à intégrer dans les matériels. Elle propose un outil de contrôle et de management, Dante Controller et vend Dante Virtual Soundcard, un logiciel pour transformer un micro-ordinateur en lecteur/enregistreur audio raccordé via son port Ethernet.
Elle annonçait récemment le logiciel Dante Via, destiné à incorporer dans le réseau Dante les périphériques audio raccordés en USB, Firewire ou autre à un micro-ordinateur de manière à élargir les sources et destinations du réseau Dante. Dante est pourvu d’un système de reconnaissance automatique des équipements avec un système d’étiquetage qui facilite leur repérage. Comme Audinate définit à la fois le protocole, les circuits électroniques et les éléments logiciels, l’interopérabilité entre les équipements pourvus d’interfaces Dante est assurée de manière automatique. Les utilisateurs reconnaissent que la mise en route et l’exploitation d’un réseau Dante sont assez faciles. Le protocole gère également la QoS à condition de mettre en place des switchs manageables.
David Rocher, directeur technique d’Agora Audio Solutions à Poitiers, a mis en œuvre plusieurs de ces protocoles : « Dante offre un meilleur jitter qu’Ethersound mais la latence augmente avec le nombre de racks. Elle n’est pas déterministe comme dans Ethersound et c’est impossible de la calculer à l’avance ».
En 2012 Yamaha a choisi d’équiper sa nouvelle gamme CL de consoles de mixage avec des interfaces Dante. Cette reconnaissance par l’un des acteurs majeurs de l’audio professionnel a donné un véritable coup d’accélérateur au succès de Dante. Yves Ansade, fondateur et directeur d’Auvitran, concepteur et fabricant de convertisseurs modulaires recevant des cartes Ethersound, CobraNet, Madi ou Dante, constate que « La plupart des constructeurs ayant choisi CobraNet ont basculé naturellement sur Dante, l’architecture matérielle et le principe d’interconnexion restant équivalents. Dante est par essence l’évolution naturelle de CobraNet ».
À ce jour, plus de 200 constructeurs d’équipements audio ont choisi ce protocole et l’ont implanté sur plus de 600 matériels. Il sert aux liaisons entre Stage box et mélangeurs audio chez Allen & Heath, AEQ, Behringer, Soundcraft… Sur de multiples unités de traitement, en sortie de récepteur de micros HF, sur des pupitres commentateur, des systèmes de microconférence (Televic et Bosch) et même directement sur des micros comme l’Audio Technica ATND971. Et même, sur le marché du corporate, Extron et Kramer proposent des interfaces ou des unités de traitement équipées en Dante.
Ravenna, l’outsider
À l’initiative de Philipp Lawo, un consortium de constructeurs d’équipements audio a lancé en 2010 un nouveau protocole de transport audio sur réseau IP, dénommé Ravenna. La démarche est à l’opposé de celle d’Audinate car Ravenna est basé sur des protocoles ouverts, comme souvent dans les architectures réseau. Cela évite les redevances à payer pour des technologies propriétaires.
Dans ce but, une structure ad hoc, ALC NetworX, a été mise en place pour développer le protocole et le populariser auprès de l’audio professionnel. Ravenna s’appuie sur de nombreux protocoles réseaux déjà existants qu’il enrichit de mécanismes pour garantir une latence faible en améliorant le respect des horloges et de la synchronisation des données.
Le système fonctionne sur réseau Gigabit Ethernet en IP au niveau de la couche 3 du modèle OSI de manière à assurer le transport des signaux à travers des routers et, plus tard, à travers des WAN. Les promoteurs de Ravenna visent le marché du broadcast, segment sur lequel Lawo est présent, et espèrent, à terme, la transmission en IP à longue distance. Ravenna regroupe actuellement 34 constructeurs parmi lesquels on relève AEQ, Aeta, Calrec, Digigram, Genelec, Merging, Sennheiser, Axia, etc.
Ravenna est prévu pour le transport de l’audio, de la vidéo et d’autres médias ainsi que pour le contrôle et la commande des équipements. Autant en unicast qu’en multicast, il supporte plusieurs flux avec des fréquences et des formats de données différents. Le protocole est transparent aux données et à leurs métadonnées. La QoS est basée sur les outils DiffServ déjà largement déployés dans les réseaux de données. Il fonctionne sur les réseaux existants et en partage avec d’autres services ou transport de données. Pour le transport des données de contenu (médias), il utilise le protocole RTP et le RTSP pour accéder et contrôler les flux. Il gère la redondance avec gestion de deux ports réseaux sur les équipements et il est totalement compatible AES67.
Ravenna a été lancé plus récemment que Dante et il est donc normal de trouver moins d’équipements équipés de cette interface. Lawo équipe sur option ses châssis de routing et certains modèles de console fonctionnant avec le châssis Dallis.
Merging Technologies, autre acteur fortement impliqué dans le rayonnement de Ravenna, a développé des drivers virtuels pour son système de postproduction audio Pyramix et les interfaces Horus et Hapi. Digigram a rendu sa gamme de codec IQOYA compatible Ravenna et commercialise une carte interface PCIe au protocole Ravenna.
L’interface de microphones Neumann DMI-8 reçoit aussi une carte Ravenna. Riedel vient d’annoncer le support des interfaces Ravenna sur ses équipements. Le constructeur de consoles radio Axia (Telos Alliance) a rendu son système de transport audio IP propriétaire Livewire compatible Ravenna. Le nombre de produits reste encore limité car comme le système est ouvert, il faut vérifier l’interopérabilité entre les systèmes au cours de plug-fest organisées régulièrement. Et ce processus s’avère plus long que pour un système propriétaire fermé contrôlé directement par un seul acteur.
AES67 pour une meilleure interopérabilité
Face à l’émergence de multiples systèmes de transport audio numérique sur réseau, l’AES a mis en place en 2010 un groupe de travail dénommé X192. Ses travaux ont abouti en septembre 2013 par la publication du standard AES67. Fonctionnant sur la couche 3 de l’OSI, il définit les spécifications minimales permettant aux constructeurs d’atteindre un premier seuil d’interopérabilité entre divers systèmes audio numériques sur réseau IP avec des performances minimales à respecter. Il détaille un format spécifique de la charge utile, des éléments de synchronisation et de QoS ainsi que des méthodes pour l’échange d’informations sur les flux audio mais sans rentrer dans l’organisation des données ni leur gestion.
AES67 est basé sur des protocoles et des principes très proches de ceux de Ravenna. En conséquence la compatibilité de Ravenna avec AES67 est assurée très simplement et d’ailleurs le consortium met en avant cet argument. Dante vient d’annoncer une mise à jour du firmware des cartes Brooklyn II pour assurer une compatibilité avec AES67 avec une coexistence des deux protocoles dans la même infrastructure. AES67 n’a pas vocation à remplacer ou à unifier les systèmes de transport audio numérique mais à assurer un dialogue limité pour leur permettre de collaborer à minima dans une infrastructure commune.
L’AVB peine à convaincre
L’IEEE est un acteur important dans les processus de standardisation des réseaux de communication. Depuis plusieurs années, il a constitué un groupe de travail destiné à adapter les réseaux informatiques au transport des signaux audiovisuels.
Leurs travaux, regroupés selon l’acronyme AVB (Audio Video Bridging), ont conduit soit à enrichir et à préciser des normes réseau existantes pour tenir compte des contraintes de synchronisation et de timing indispensables au transport du son et de la vidéo et aussi d’en créer de nouvelles. Sont regroupés sous ce vocable AVB, une série de standards précisant chacun un élément technique précis : horloge et synchronisation, gestion des priorités, affectation de la bande passante, dialogue entre les équipements et les actifs réseau.
L’ensemble, qui a déjà demandé plusieurs années d’études et de mise au point, a été publié par étapes depuis 2011 et continue à faire l’objet de propositions et de publications tant le champ d’études est vaste.
Les mécanismes de synchronisation et de gestion du trafic AV ne peuvent être assurés au niveau des équipements actifs réseau traditionnels et exigent des capacités de traitement à l’intérieur même des switchs. Le transport des flux AVB est donc exploité via des switchs réseau spécifiques et conformes à la norme AVB. Les communications entre équipements sont établies au niveau de la couche 2 du modèle OSI et restent donc cantonnées dans un sous-réseau sans capacité de routage IP. Dans un réseau AVB, 75 % de la bande passante est affectée aux flux audiovisuels et le reste disponible pour les services réseaux classiques (gestion, échanges de données, consultation de serveurs…).
Les initiateurs de l’AVB visent à la fois le marché domestique, l’automobile et l’audiovisuel professionnel. Pour garantir l’interopérabilité entre les équipements conformes aux standards AVB, une soixantaine d’industriels (Broadcom, Cisco, Harman, Intel…) ont créé l’AVnu Alliance avec l’objectif de mettre en place une certification des matériels commercialisés. Compte tenu du nombre de paramètres et de fonctionnalités incluses dans l’AVB, les procédures sont longues et complexes, et dans le domaine AV, le nombre d’équipements conformes à l’AVB reste limité : des processeurs audio chez Meyer, Soundweb, BiAmp, des amplis chez Crown, le système de mixage Avid Venue S6L, des interfaces Motu…
Le succès de l’AVB reste entravé par l’utilisation de switchs réseau spécifiques. Sur une opération mobile, le prestataire pourra mettre en place ses propres switchs réseaux conformes à l’AVB. Mais peut-on imaginer une DSI obligée d’installer des actifs réseau spécifiques sous la pression du service audiovisuel ? La complexité du standard et son évolution permanente n’aident pas non plus à sa diffusion. Ce que confirme Yves Ansade : « On a beaucoup parlé d’AVB il y a quelques années. Cette technologie était promise à un très grand avenir mais elle reste dépendante d’une infrastructure réseau AVB. Malgré l’arrivée de l’alliance AVnu, elle souffre d’un manque de standardisation avec beaucoup de variantes intermédiaires incompatibles entre elles. Un grand nombre de constructeurs impliqués dans l’AVB, y compris Harman, proposent des solutions basées sur Dante en attendant une vulgarisation de l’AVB. »
Quel protocole choisir ?
Face à la prolifération de ces nouveaux systèmes de transport audio numérique, le choix d’une architecture et d’un protocole n’est pas chose aisée. Le standard AVB, né sous les meilleurs auspices et dans lequel de nombreux acteurs mettaient beaucoup d’espoir, peine à se concrétiser. Basé sur des standards indépendants des constructeurs, il aurait pu rassurer les futurs exploitants. Mais le projet était sans doute trop ambitieux. Certains experts estiment que son indépendance et son intégration aux multiples normes des réseaux pourraient, à terme, le faire revenir sur le devant de la scène. Mais n’a-t-il pas laissé passer sa chance face à un système plus propriétaire et qui étend sa toile chaque jour. À propos de Dante, puisqu’il s’agit de lui, Audinate affirme que son système pourra s’intégrer aussi dans AVB.
Les constructeurs d’équipements audio sont aussi dans la perplexité et, selon le vieil adage paysan, ne souhaitent pas mettre tous leurs œufs dans le même panier. Ainsi Sennheiser, pourtant membre de l’AVnu Alliance, support de l’AVB, installe une carte Dante dans l’un de ses récepteurs de micros HF. Riedel a toujours affirmé son soutien à AVB et pourtant ajouté un port AES67 à sa plateforme d’échange Tango. L’entreprise vient de rejoindre Ravenna. Avid avait choisi aussi AVB pour la liaison Stage Box vers console pour sa Venue SL6 et vient d’annoncer une interface Dante pour celle-ci. Cette tendance à l’ouverture vers la multiplicité des réseaux est confirmée par Yamaha qui, pour sa nouvelle console PM10, s’appuie sur deux architectures : TwinLANe pour le raccordement des stage box en fibre optique avec une capacité de 400 canaux et Dante pour l’interconnexion des équipements de production en aval. David Rocher confirme cette approche : « On ne va pas choisir une console de mixage en fonction du protocole utilisé. Sur les plus gros projets, on exploite différents réseaux en fonction du niveau de communication recherché et des performances. L’espéranto de l’audio numérique n’est pas encore né ! »
Le protocole ACIP – 1 184 C
Les protocoles décrits dans cet article sont destinés au transport audio multicanal, sans compression et privilégiant une faible latence, car ils sont destinés au « live » et ne doivent pas perturber l’écoute en direct. D’autres protocoles de transport audio numérique sont utilisés pour les liaisons de contribution : reportage d’actualités, retransmission en direct d’événements. Ils empruntent sur de longues distances les réseaux IP d’Internet, quel que soit le support physique. Sur les WAN, Internet n’offre pas encore de QoS et ces protocoles doivent donc offrir des outils de correction d’erreur et un faible jitter face aux aléas de la transmission en mode paquets. Pour réduire la bande passante, un algorithme de compression est aussi mis en œuvre (APTx, AAC, MPEG, G.711, G.722…). De nombreux constructeurs comme Digigram, AETA, Worldcast, AEQ, Luci, Mayah, Tieline, etc. proposent des codecs, des matrices ou des consoles de reportage avec des interfaces IP. Pour encourager l’interopérabilité entre tous ces systèmes, l’EBU, à travers un groupe de travail, a défini un cœur de prescriptions sous la recommandation Tech. 3326, dénommé aussi ACIP, Audio Contribution over IP.
