Les réseaux informatiques font rêver depuis que l’audio numérique est devenue une banalité. En effet, leur coût de mise en œuvre est modique, le câblage léger et facile à réaliser (on peut même, de plus en plus souvent, fonctionner « sans fil »), et les débits max annoncés de 100/1000 Mbits/s laisse imaginer leur capacité à véhiculer des signaux audio (réputés de « basse fréquence »), avec facilité. Hélas, ce n’est pas toujours le cas et la mise en pratique de réseaux numériques dans le domaine audio professionnel est souvent un sujet d’angoisse, lorsqu’il ne s’agit pas de grosse prise de tête.

[private]

Lorsqu’on doit réaliser des liaisons audionumériques, le premier réflexe est d’utiliser les interfaces standard disponibles sur les appareils. La plus fréquente est l’AES-3, qui véhicule deux canaux audio sur une paire torsadée équipée de connecteurs XLR. Utiliser plusieurs de ces liaisons, avec une portée utile de quelques dizaines de mètres, reste possible, mais il est de très grosses installations pour lesquelles cela devient cauchemardesque. Il existe bien des standards qui autorisent des liens multicanaux (MADI, ADAT, etc.), mais ils ont des inconvénients propres à chacun comme une portée limitée ou un nombre de canaux qui s’avère rapidement insuffisant.

Si on regarde du côté des liaisons strictement informatiques, on retombe sur des problèmes similaires, qu’il s’agisse de l’USB ou de l’IEEE 1394.

Ainsi, les installations fixes comprenant plusieurs points névralgiques (scènes, cabines techniques, studios d’enregistrements, salles de répétitions, etc.) interconnectés en multicanal et les grandes prestations de concerts avec scène, diffusion et retours, constituent des cas typiques où les liaisons traditionnelles (analogiques ou numériques), mêmes regroupées au sein de câbles multipaires (« snakes ») gros comme le python qui vient d’avaler l’antilope sont deux cas typiques ou la mise en œuvre d’un réseau unifie et simplifie le problème tout en instaurant une flexibilité rarement atteinte.

En effet, c’est de manière tout à fait abusive qu’on parle de réseau en ce qui concerne les types de liaison précédemment évoqués. Les fonctions d’un réseau incluent, certes, la transmission des signaux, mais aussi leur routage (modifiable à la demande sans intervention sur les interconnexions physiques), ainsi que diverses fonctions de commande, de contrôle et d’administration de l’ensemble du système. Ainsi il est possible, via un unique réseau, d’acheminer des signaux audio dans diverses directions, de régler le gain des préamplificateurs, de visualiser l’état des appareils et de recevoir des alarmes en cas de dysfonctionnement. Chaque appareil et quelquefois chaque sous-fonction de chaque appareil est visualisée sur l’écran de l’ordinateur qui pilote le réseau au travers d’un logiciel aussi convivial que possible.

Un réseau ainsi conçu comporte tout de même quelques contraintes, telles que, par exemple, la nécessité que tous les signaux audio soient échantillonnés à la même fréquence et synchronisés entre eux, ce qui confirme le caractère local de ce type de réseau. La synchronisation est véhiculée via le réseau à partir d’un appareil choisi comme horloge mère.

Quelques principes de base dans les réseaux informatiques

Le réseau informatique standard le plus fréquemment utilisé aujourd’hui, qui offre les moindres coûts du fait de son déploiement massif et de ses éléments fabriqués à grande échelle, est Ethernet (IEE802), également souvent appelé « réseau IP ». Ces appellations mènent souvent à la confusion car elles désignent, en fait, différentes couches de protocole réseau, habituellement utilisées conjointement (donc sans distinction au niveau de l’utilisateur) dans les applications informatiques.

– Couche physique (niveau 1) : Divers types de support physique peuvent véhiculer les signaux de ce type de réseau, avec divers débits : câble coaxial (obsolète), câble à paires torsadées, fibres optiques monomodes et multimodes, liaison radio, voire lasers en vue directe. Le plus fréquent est le câble à paires torsadées Cat.5 à 100 Mbits/s. On trouve aussi fréquemment des interfaces à 1 Gbit/s. Dans la pratique, lorsqu’on parle de réseau en audio, on sous-entend le plus souvent câble à paires torsadées (Cat. 5/5e/6). Le connecteur recommandé est le connecteur en plastique « de style téléphonique » RJ-45, mais celui-ci est assez fragile. En particulier, la languette qui assure le verrouillage a tendance à casser au bout de quelques manœuvres et, en cas de traction sur le câble, le connecteur peut facilement s’arracher. En audio professionnel (et surtout en touring !), on recommande plutôt l’utilisation de câbles renforcés mécaniquement et du connecteur « EtherCon » proposé par Neutrik. Il s’agit d’un connecteur RJ-45 protégé par une coquille métallique à verrouillage et serre-câble robuste analogue à celle des connecteurs XLR (voir photo). La longueur maximale recommandée d’un bond de câble est de 100 m. Au-delà, on doit faire appel à plusieurs bonds reliés par un ou plusieurs répéteurs, ou bien, si la distance visée est considérablement plus grande, à un bond en fibre optique.

– La couche de niveau immédiatement supérieur (niveau 2) est dite Ethernet (figure 1). Elle fait appel à la notion d’adresse MAC (une adresse unique stockée « en dur » dans chaque matériel, qui l’identifie sur le réseau). Le protocole d’origine prévoit une topologie physique en étoile, où les messages sont émis vers l’ensemble des éléments connectés au réseau, un algorithme exécuté par chaque émetteur potentiel permettant d’éviter les collisions et embouteillages (dans cette logique, un seul émetteur doit « parler » à la fois). Dans la version moderne, on utilise des commutateurs et non plus des simples répéteurs (hubs) aux embranchements de l’étoile, de sorte que plusieurs émetteurs peuvent s’activer simultanément. Le protocole d’évitement des collisions est alors désactivé, mais celui-ci reste obligatoire dans certaines configurations, par exemple lorsque le réseau utilise un lien radio.
Les messages sont de longueur variable et il n’y a ni synchronisation, ni cadence fixe de trames.

– La couche supérieure (niveau 3) est appelée couche IP (Internet Protocol) parce qu’elle fait appelle à la notion d’adresse IP. Ce protocole ne gère en rien la sûreté de fonctionnement du réseau, qui doit être assurée, si nécessaire, par les couches de niveau supérieur. (figure 2)

– La couche transport peut utiliser plusieurs protocoles différents selon l’application. Cela correspond à des syntaxes de messages différentes. UDP est le protocole simple, sans vérification de la transmission, qui s’adapte le mieux aux liaisons audiovisuelles. TCP est un protocole plus compliqué qui assure la sûreté de transmission par un processus de dialogue avec accusés de réception et réémission en cas de perte ou d’erreur. Il existe bien d’autres protocoles que nous ne décrirons pas ici (voir figure 3).

Les principaux inconvénients des standards usuels

Dans la pratique, dans un réseau Ethernet/IP moderne, un message est émis vers une ou plusieurs destinations, voire l’ensemble des éléments connectés au réseau (unicast, multicast ou broadcast) et le réseau doit se charger de l’acheminer en faisant usage de ses ressources réparties. Les commutateurs modernes sont dotés d’intelligence et de mémoire. Ils sont capables de déchiffrer à la volée les en-têtes des messages et les adresses de destination afin d’orienter les messages vers les bonnes branches, d’effectuer certaines modifications sur les en-têtes de messages (par exemple : translation d’adresses), des vérifications (checksums), et de gérer des files d’attente dans les directions les plus chargées. Il en résulte que le délai d’acheminement n’est pas garanti et est fondamentalement variable. Pire encore, l’ordre d’arrivée des messages n’est pas garanti non plus, il n’est pas forcément conforme à l’ordre d’émission (certains messages peuvent rester « coincés » un certain temps dans des files d’attente alors que d’autres peuvent passer plus directement). Rappelons que la notion de « temps réel », souvent mal comprise, implique que le temps de transmission soit prédictible (mais en aucun cas qu’il soit nul). C’est pourquoi IP et temps réel sont des ennemis héréditaires. Qui plus est, les protocoles réputés « sûrs » comme TCP, dans lesquels un message manqué ou erroné provoque une répétition (voire plusieurs en cas de récidive), sont fondamentalement contradictoires avec les contraintes du temps réel.

En conclusion, les grands réseaux informatiques sont une plaie pour les signaux audiovisuels à cause du temps de transmission variable. En audio, cela provoque du jitter, en vidéo, des pertes de synchronisation. Dans tous les cas, il peut y avoir des pertes d’échantillons, dont l’effet est plus ou moins désastreux selon le contexte. Cela pourrait bien s’arranger grâce à une mémoire tampon d’une taille suffisante pour absorber tous les aléas de la transmission. Cette solution fait merveille dans le streaming sur Internet, mais elle n’est pas acceptable en audio professionnel du fait du retard (latence) qu’elle introduit (plusieurs secondes), totalement rédhibitoire pour les applications de spectacle vivant (ou de vidéo en duplex pour la télévision). Même avec les solutions propriétaires qui éliminent la variation de latence, l’inconvénient majeur reste la latence elle-même dans sa valeur absolue. Au-delà de quelques millisecondes, elle n’est plus acceptable.

Les solutions habituelles

Un principe général doit être retenu dans la mise en œuvre de réseaux pour l’audio professionnel : le réseau doit être dédié. Si cette contrainte semble aller de soi pour les spectacles itinérants, elle est moins évidente pour les installations fixes, où des informaticiens possèdent souvent un réseau pour la gestion, qu’ils imaginent pouvoir utiliser conjointement pour l’audio, réputé « à bas débit ». Il ne faut pas imaginer pouvoir partager la ressource avec un trafic informatique digne de ce nom. Ainsi, un réseau audio pourra supporter les données supplémentaires à bas débit pour le contrôle des machines de l’exploitation (réglages de gain, etc.), mais guère plus, sans manifester de perturbations.

Trois standards de réseau audio propriétaires ont connu et/ou connaissent encore actuellement un certain succès (mais il y en bien d’autres). Dans l’ordre d’apparition :

• – CobraNet
• – EtherSound
• – Dante

CobraNet et EtherSound utilisent le câble à paires torsadées et le protocole de niveau 2 mais pas le niveau 3. Ils ne sont donc pas compatibles avec la plupart des applications de réseau informatiques. Encore très présent dans les installations aux USA, CobraNet est sur le déclin et n’est pratiquement plus proposé pour les nouveaux systèmes. EtherSound est, quant à lui, à maturité et encore susceptible d’évoluer. Il faut prendre garde, avec ces standards propriétaires de réseau audio, à la compatibilité avec les éléments d’infrastructure. En particulier, les commutateurs, routeurs et interfaces de média (câble/fibre optique) peuvent poser problème.
Plus récemment arrivé et maintenant vraiment au point, Dante exploite le protocole IP complet, mais avec un dispositif particulier (normalisé) pour la synchronisation et une gestion de la priorité des messages. Bien que plus proche d’une approche standard W3C, et, à ce titre, plus capable de cohabiter avec un certain trafic informatique (ce que nous n’encourageons tout de même pas, …), Dante reste propriétaire.

AVB : une solution standardisée

Constatant le fait que les applications à fortes contraintes temporelles sur réseau faisaient l’objet d’une forte demande et de solutions propriétaires, l’IEEE a développé, par l’intermédiaire de son Audio Video Bridging Task Group, un ensemble de standards internationaux complétant les normes de réseau IEEE 802.1 appliqués par ailleurs. Connus sous le terme AVB, ils constituent la réponse des instances normatives aux besoins industriels. Comme leur nom l’indique, ils sont adaptés au transport de l’audio, mais aussi de la vidéo en temps réel.

Couvrant les principaux aspects défaillants des standards courants, les nouveaux textes sont :

• – IEEE 802.1AS: Timing and Synchronization for Time-Sensitive Applications
• – IEEE 802.1Qat: Stream Reservation Protocol (SRP)
• – IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams (FQTSS)

Le dernier : IEEE 802.1BA : Audio Video Bridging Systems regroupant les prescriptions générales pour les systèmes.
On notera une forte ressemblance avec Dante, qui peut être qualifié de précurseur. IEEE 801.1Qat et Qav sont des amendements du texte de base IEEE 801.1Q qui concerne essentiellement les commutateurs. Ils consistent à spécifier des mécanismes destinés à réserver une partie du débit disponible pour les données prioritaires (c’est-à-dire audiovisuelles) et la gestion des files d’attente ainsi qu’un mécanisme d’anticipation pour lesdites données. IEEE 802AS introduit un système de synchronisation qui est en fait un dérivé à contraintes renforcées du protocole IEEE 1588 (PTP) utilisé par Dante et par les applications d’instrumentation industrielle.

Bien entendu, les éléments conformes AVB peuvent aussi communiquer avec les éléments qui ne supportent pas le protocole. Mais il est clair que les mécanismes d’acheminement particulier des données prioritaires et de synchronisation ne pourront franchir ce dispositif. IEEE 802.1BA inclut donc des mécanismes permettant d’identifier tous les éléments connectés au réseau qui supportent AVB, et également de reconnaître ceux qui ne le supportent pas et de les cataloguer. Bien entendu, les liaisons AVB ne peuvent pas traverser les passerelles non-AVB, même si les composants en aval supportent le protocole.

Grâce au processus de réservation de bande et de gestion de la priorité d’acheminement, une latence de 2 ms seulement est revendiquée pour un trajet incluant 7 commutateurs sur un réseau AVB à 100 Mbits/s. Sur un réseau Gigabit, la latence brute serait de 25 µs pour chaque commutateur. Cela donne, pour l’ensemble d’un réseau, une latence globale largement inférieure à celle d’un couple de convertisseurs A/N et N/A en cascade.

Les différents textes ont été adoptés et publiés en tant que normes officielles et « définitives » en 2010 et 2011. L’interopérabilité et la conformité aux normes est l’affaire de l’alliance AVnu, qui regroupe les industriels majeurs du secteur et qui élabore les tests de conformité (www.avnu.org). Sachant que les principaux acteurs du marché ont largement anticipé la publication définitive des textes, on devrait voir bientôt apparaître des équipements audio conformes à ce protocole. Quant aux éléments d’infrastructure, il semble clair que les principaux fabricants de commutateurs intelligents sont prêts à intégrer les nouveaux standards dans leurs produits. Par exemple, NetGear a annoncé, conjointement avec Harman (BSS audio), la sortie des premiers switches (16 et 24 ports) compatibles AVB à InfoComm en juin 2009. BSS audio présentait d’ailleurs à Prolight&Sound les versions AVB (64 canaux en entrée et en sortie à 48kHz ou 32 en 96 kHz) de ses processeurs 800 et 320 Cobranet, référencés respectivement BLU-825 et 325. Soundcraft (groupe Harman également) a annoncé récemment la disponibilité prochaine de cartes d’extensions compatibles AVB pour ses consoles des séries Vi, Si Compact et Si1/2/3.

Dans la pratique, il devrait être facile d’intégrer des réseaux AVB dans les appareils et le statut de standard international devrait faciliter l’administration et l’exploitation de tels réseaux au travers de logiciels conviviaux. En revanche, le statut de norme internationale ne dispense pas les fabricants et/ou intégrateurs de s’acquitter des redevances relatives à l’usage des principes brevetés qui font l’objet de la norme, et qui devraient faire l’objet d’acquisition de licences, ce qui pourrait freiner l’adoption du standard.

Conclusion

Plus on se rapproche de solutions normalisées et plus les systèmes sont « ouverts ». C’est ce qui explique que Dante soit plus facile à mettre en œuvre que les autres systèmes de réseau, mais cela ne signifie pas qu’on puisse faire n’importe quoi. Ainsi avec AVB, on s’attend à une plus grande simplicité mais il ne faut pas crier victoire trop tôt. AVB ne fonctionnera bien que si l’ensemble de l’infrastructure est équipée d’éléments compatibles. AVB ne signifie pas non plus que la cohabitation entre l’audiovisuel professionnel et l’informatique « traditionnelle » sera totale sur n’importe quel réseau. Elle ne redonnera pas aux informaticiens la maîtrise totale des systèmes que l’apparition des standards propriétaires dédiés à l’audio leur avait fait perdre. En cas de congestion du réseau, il faut qu’ils sachent que ce sont eux qui devront faire des concessions et non l’inverse. Enfin, AVB étant nouveau, il est clair que les règles de mise en œuvre précises et les difficultés d’exploitation se révéleront au fur et à mesure des expériences de terrain, dont nous ne manquerons pas de vous faire part. La diversité des produits disponibles est encore trop insuffisante pour qu’AVB puisse être considéré comme un standard mature. Mais à terme, avec AVB, on peut espérer la banalisation du réseau audio et vidéo, devenu facile et bon marché.

CobraNet : créer l’isochronisme sur Ethernet en couche 2.

CobraNet a été développé comme une alternative au câblage analogique dans les grandes installations audio fixes. C’est la première réalisation commerciale de l’audio sur Ethernet. La Société Peak Audio (Colorado) a présenté le réseau CobraNet en 1996, acquise en 2001 par la société Cirrus Logic. Le support physique est Ethernet 100 jusqu’à la couche transport, mais les paquets CobraNet disposent d’un identifiant “ Longueur/Type ” particulier (0x8819) attribué à Cirrus Logic (figure 4). L’adressage repose uniquement sur les adresses MAC et non sur les adresses IP. Chaque élément CobraNet possède deux ports Ethernet repérés “ primaire ” et “ secondaire ”, qui fonctionnent en mode redondant. En fonctionnement normal, c’est le port primaire seul qui travaille, mais si la connexion tombe en panne, le port secondaire prend automatiquement le relais. Cela permet de raccorder chaque élément CobraNet par des commutateurs différents, pour réaliser des architectures de réseau totalement redondantes, en utilisant des commutateurs intelligents qui supportent le protocole IEEE802.1w dit “ Spanning Tree Protocol ” (STP).
Dans un réseau CobraNet, la base en termes de routage audio est le “ bundle ”. qui représente l’unité élémentaire de flux de données pour le transport de l’audio. Le nombre maximum de canaux audio par bundle est typiquement de 8 mais peut être inférieur dans certaines configurations particulières.
Les bundles peuvent être transmis selon différents modes :
– Unicast (point à point)
– Multiple Unicast (jusqu’à quatre unicast vers plusieurs récepteurs)
– Multicast (un bundle vers un nombre illimité de récepteurs)
– Privé (comme unicast ou multicast, mais nécessite de spécifier une adresse MAC).
Le réseau est synchronisé par un élément appelé chef d’orchestre (“ conductor ”). Quatre types de paquets interviennent dans la communication CobraNet :
– Synchronisation (“ Beat Packets ”) : Ces paquets sont émis en multicast avec l’adresse MAC de destination 01:60:2B:FF:FF:00. Le chef d’orchestre émet un paquet “ beat ” à raison de 750 par seconde (soit une période de 1,333… ms) à destination de tous les éléments du réseau. Tous les autres éléments audio du réseau synchronisent leur horloge audio et leur transmission de données sur ces paquets “ beat ”. Les paquets “ beat ” déterminent des intervalles de transmission isochrone et contiennent des paramètres de fonctionnement du réseau (notamment les données de routage), les données d’horloge et les autorisations pour l’émission de bundles unicast et multicast.
– Paquets audio (ou données isochrones). Ces paquets sont émis par tous les composants du réseau après réception d’un paquet “ beat ”, avec un adressage de type unicast ou multicast selon le type de bundle et le nombre de destinations. Au réglage de latence standard, un paquet audio est émis pour chaque paquet “ beat ” reçu, et chaque paquet audio transmet 64 échantillons audio par canal. Aux réglages de latence plus faible, les paquets audio peuvent être émis deux fois ou quatre fois à chaque paquet “ beat ” reçu. Les bundles ne partagent pas de paquets : les différents paquets de chaque bundle émis par un même élément sont transmis à la suite. Les paquets isochrones sont souvent relativement longs (1 000 octets et plus).
– Les paquets de réservation (“ reservation packets ”) Ces paquets sont émis lorsque c’est nécessaire, au moins une fois par seconde, avec l’adresse multicast 01:60:2B:FF:FF:01. Leur fonction est de contrôler les allocations de bande passante, d’établir les liaisons entre éléments CobraNet et de surveiller l’état des différents éléments CobraNet du réseau.
– Les paquets de passerelle série (“ serial bridge packets ”) permettent de transmettre des données asynchrones entre composants CobraNet sur le même réseau (typiquement des commandes ou des informations d’état relatives aux éléments distants connectés au réseau). Cette liaison supporte divers standards comme RS-232/422/485, MIDI, etc.
Dans la configuration standard, la formation des paquets audio implique un délai (purement numérique) de 256 échantillons, soit 5,333 ms (à 48 kHz), correspondant à 3 périodes du rythme “ beat ”. On peut réduire la latence, simplement en faisant usage de paquets plus petits, émis plus souvent. Il est ainsi possible de programmer les réseaux CobraNet pour obtenir une latence de 5,333, 2,666 ou 1,333 ms.
Pour la conception et la simulation du réseau, Cirrus Logic fournit un logiciel dénommé CobraCAD doté d’une interface graphique. L’administration peut se faire par le logiciel Discovery (CobraCAD et Discovery peuvent être téléchargés gratuitement sur le site www.cobranet.info) ou, via le réseau, par SNMP (Simple Network Management Protocol).

EtherSound, le réseau « audiosynchrone »

Conçu au sein de la société française Digigram, puis développé par AuviTran, EtherSound est un standard de réseau audio propriétaire qui exploite la couche 2 d’Ethernet et dont le premier brevet remonte à 2001. La version actuelle est la troisième, dite ES100, qui retient une transmission bidirectionnelle sur un réseau connecté en chaîne ou en anneau pour la redondance. Chaque élément EtherSound comporte donc deux ports pour le réseau et un troisième auquel on peut connecter l’ordinateur qui administre l’ensemble.
EtherSound ne fait appel qu’à un seul type de trame, diffusé à la fréquence d’échantillonnage des signaux audio. Cette trame inclut l’audio, les informations de routage et d’éventuelles commandes ou informations d’état pour la gestion des éléments connectés au réseau (figure 5). Sur le réseau EherSound, il y a un “ Chef d’Orchestre ” qui synchronise tout le réseau en émettant une trame qui comporte des “ cases vides ”, dans laquelle les autres éléments du réseau peuvent insérer du contenu. L’ensemble du réseau est donc synchronisé à l’audio, dont la cadence impose le rythme d’émission de la trame EtherSound. Divers mécanismes permettent de lutter contre les fluctuations temporelles de la synchronisation, dont une horloge à boucle de phase dans chaque interface EtherSound et un compteur dans chaque trame, permettant de vérifier la continuité de la réception et de pallier la perte de paquets.
La latence est imputable uniquement aux éléments du réseau (temps de propagation, temps nécessaire à la lecture, à l’insertion de contenu audio dans la trame, à la modification des en-têtes, à la vérification et à la mise à jour des CRC). L’avantage d’EtherSound par rapport à d’autres solutions comme CobraNet est que la latence est faible, mais surtout qu’elle est constante d’un point à un autre et rigoureusement déterministe. Elle peut être calculée à l’aide de quelques chiffres de base, en ajoutant les latences cumulées des différents éléments séparant les deux points considérés :
– De point à point : 5 échantillons (2+1+2), soit 104 µs à 48 kHz.
– au travers d’un module EtherSound : 1,4 µs (c’est le temps nécessaire à régénérer les préambules)
– au travers d’un commutateur : 20 µs (retard d’une trame augmenté du temps nécessaire à la vérification du CRC)
– Selon la distance : 0,4 µs pour chaque longueur de 100 m de câble Cat.5.
Dans le cas des convertisseurs de média (par exemple si le réseau inclut un tronçon de fibre optique), un retard supplémentaire est inévitable (consulter la notice du fabricant du produit). La latence étant liée à la période d’échantillonnage, elle est un peu plus élevée en 44,1 kHz qu’en 48 kHz (la période de base passe de 20,83 µs à 22,67 µs, ce qui donne 113,28 µs pour la liaison de point à point). Pour les fréquences d’échantillonnage supérieures (96 ou 192 kHz par exemple), il n’y a pas de changement, car celles-ci sont obtenues en transmettant 2 échantillons ou 4 échantillons, en conservant la fréquence et la structure de la trame à 48 kHz. Evidemment, la capacité du réseau (en termes de canaux audio synchrones) est divisée par deux ou par quatre.
EtherSound dispose nativement de fonctions d’administration du réseau, telles que l’énumération, la détection de la hiérarchie et la détection des erreurs de connexion. Le logiciel ES-Monitor AuviTran est l’outil de gestion des réseaux EtherSound. Outre les fonctions d’administration du réseau et de routage audio, il permet la commande à distance de certains modules (gains, activation du 48 V, VU mètres, etc.). Il inclut les interfaces pour de nombreux appareils qui peuvent être contrôlés de manière totalement transparente via le réseau. Des fonctions de surveillance et de diagnostic sont également intégrées.
La réalisation du routage demande une réflexion préalable et ne doit pas être confiée aux automatismes du logiciel.
Les architectures et configurations validées peuvent être sauvegardées et rappelées à tout moment dans ES-Monitor. Le logiciel dispose d’un mode non connecté “ off-line ”, dans lequel on peut créer et simuler des installations virtuelles et les sauvegarder pour une utilisation ultérieure. Cette fonction sera très appréciée par les architectes et intégrateurs qui pourront commencer à mettre au point les systèmes avant l’achèvement des travaux et finaliser les derniers réglages sur l’installation réelle en réduisant au minimum de pertes de temps. L’outil intègre tous les appareils reconnus par ES-Monitor.

Dante : utiliser malgré tout les protocoles IP…

Suite à la fermeture d’un laboratoire de recherche australien de Motorola, l’actuel directeur technique d’Audinate, Aidan Williams, constitua au sein du National Information and Communication Technology Australia (NICTA), avec l’aide du gouvernement australien, une équipe de chercheurs qui passa trois ans (2003-2006) à définir les bases de ce qui allait devenir Dante. En 2006, Williams fonda la société Audinate pour commercialiser Dante. La première installation utilisant Dante a été réalisée en 2008. Les promoteurs de Dante revendiquent de multiples avantages sur les systèmes de réseau audio préexistants (CobraNet, EtherSound) : la possibilité de passer au travers des routeurs standards de réseau, le support natif de l’Ethernet Gigabit, un nombre de canaux plus élevé, une plus faible latence et la configuration automatique.
Contrairement à CobraNet et EtherSound, qui considèrent que les protocoles IP de couche 3 sont inutilisables pour l’audio et construisent des protocoles propriétaires au-dessus de la couche 2, Dante n’utilise que les protocoles IP standards. De ce fait, Dante revendique une compatibilité totale avec les équipements de réseau utilisés par ailleurs, et, notamment, la cohabitation possible de trafic audio Dante avec du trafic TCP/IP de même nature que celui qu’on trouve habituellement en bureautique (Internet, e-mails, etc.), sans conséquence dommageable pour l’audio. Dante se fonde sur une transmission au sein de paquets UDP (figure 6). Chaque paquet UDP du trafic Dante peut contenir plusieurs échantillons audio d’un même canal et des échantillons audio de plusieurs canaux différents. La taille des paquets est choisie automatiquement par le système pour réaliser le compromis entre une bonne utilisation du débit disponible et maintenir la latence aux valeurs spécifiées. Le protocole UDP permet une transmission directe entre une adresse IP d’origine et une adresse IP de destination (multicast ou broadcast), sans délai et sans accusé de réception.
Dante exploite les caractéristiques de Qualité de Service (QoS) des commutateurs standards pour la voix sur IP (VoIP) pour établir une priorité des signaux de synchronisation et d’audio sur le reste du trafic circulant sur le réseau (IEEE 802.1Q). Tout commutateur qui supporte les services différenciés (Diffserv) avec priorité stricte, la qualité de service avec quatre files d’attente et qui possède des ports Gigabit Ethernet pour la connexion entre commutateurs devrait convenir pour fonctionner avec Dante. Diffserv fait appel à un champ de 6 bits dénommé Differentiated Services Code Point (DSCP) situé dans l’en-tête des paquets IP, destiné à classifier le trafic. L’attribution des priorités à chaque classe de trafic est réalisée extérieurement au protocole.
Dante repose également sur des horloges locales synchronisées sur une horloge particulière du réseau. La synchronisation exploite le protocole IEEE1588 dit PTP (Precision Time Protocol), qui s’appuie sur un échange de paquets UDP. Le dialogue permet à chaque horloge de déterminer le temps de propagation entre l’horloge-mère et elle-même et de le compenser. Ce système de synchronisation est totalement indépendant du trafic audio. Les horloges servent à horodater les paquets audio, de telle manière que le système puisse gérer leur ordre d’arrivée et détecter d’éventuelles pertes de paquets. Les fréquences d’échantillonnage acceptées sont 48 et 96 kHz, avec des profondeurs de codage de 16 et 24 bits.
On notera que la hiérarchisation du trafic est voisine de celle d’AVB, avec lequel Dante revendique la compatibilité.
Dante intègre un mécanisme grâce auquel chaque élément Dante connecté au réseau peut automatiquement découvrir les autres et se configurer dès qu’il est raccordé au réseau. C’est une approche de type plug & play. Chaque canal audio peut recevoir un nom (étiquette) plus parlant qu’un numéro ou une adresse numérique. Cette possibilité facilite le routage. Comme pour les composants informatiques plug & play, ces informations sont stockées dans une mémoire non volatile incluse dans chaque élément et restent disponibles, même si l’élément a été mis hors tension. A la première utilisation, les éléments portent des étiquettes “ par défaut ” qu’on peut remplacer par des nouvelles plus parlantes dans le contexte spécifique de l’application (les adresses IP sont gérées par le protocole du style DHCP et l‘utilisateur n’a pas à s’en occuper si le réseau intègre un serveur DHCP). Les interfaces de contrôle de chaque élément sont spécifiques à chaque constructeur. Leur usage intensif peut engendrer de pertes de paquets. Dante ne propose pas de système de simulation de réseau hors ligne analogue à celui d’EtherSound.
La topologie du réseau Dante est standard, c’est à dire typiquement en étoile avec des commutateurs. On peut sécuriser le réseau en doublant les commutateurs. La redondance des chemins est alors gérée par le protocole STP (Spanning Tree Protocol), normalisé sous la référence IEEE802.1d
Audinate indique une latence minimale de 84 µs (soit 4 échantillons à 48 kHz). Dans la réalité, ce chiffre correspond liaison de point à point en Ethernet 1 Gbit/s sans aucun élément intermédiaire (switch ou autre) et ne correspond pas à une véritable configuration en réseau. Concrètement, les chiffres se montent à 150 µs pour deux cartes Yamaha MY16-AUD raccordées directement en point par point par une liaison 1 Gbit/s et au moins 800 µs pour un PLM de Lab Gruppen (amplificateur à DSP) sur réseau 100 Mbits/s. Dans la pratique, la latence dépend fortement de l’infrastructure du réseau. S’il y a plus d’un switch entre l’émetteur et le récepteur sur un réseau Gigabit Ethernet, la latence s’élèverait à 0,5 ms.
La latence est également ajustable par configuration des éléments Dante, avec des valeurs minimales (par exemple 150 µs sur carte MY16-AUD) et des valeurs plus conservatives (5 ms pour la même carte), avec des valeurs intermédiaires de 0,5 et 1 ms selon le nombre de commutateurs intercalés dans le réseau.
Le nombre maximum de canaux audio pris en charge est de 48 dans chaque direction (24 bits/48 kHz sur réseau 100 Mbits/s), 64 canaux dans chaque direction pour chaque élément sur réseau 1 Gbit/s et pour l’ensemble du réseau 1 Gbit/s avec des commutateurs convenables, un maximum de 512 x 512 canaux.
Le logiciel d’administration des réseaux Dante, appelé Dante Controller, gère le routage audio matriciel d’une manière similaire au logiciel équivalent d’AuviTran pour EtherSound.

[/private]