RTP MIDI

Un article de Wikipédia, l'encyclopédie libre.

RTP-MIDI (également connu sous le nom « AppleMIDI ») est un protocole destiné au transport de messages MIDI dans des messages RTP (Real-Time Protocol), sur des réseaux Ethernet et Wi-Fi. Ce protocole est entièrement ouvert et libre (aucune licence nécessaire), et il est compatible à la fois avec les applications de type réseau local (LAN) et réseau étendu (WAN). Comparé à MIDI 1.0, RTP-MIDI apporte de nouvelles fonctionnalités comme la gestion de sessions, la synchronisation temporelle des appareils et la détection des messages perdus (avec régénération automatique des données perdues). RTP-MIDI est compatible avec les applications temps-réel, et supporte la synchronisation à l'échantillon près (« sample accurate ») pour chaque messages MIDI.

Histoire de RTP-MIDI[modifier | modifier le code]

En 2004, John Lazzaro et John Wawrzynek, de l'université UC Berkeley, firent une présentation devant l'AES nommée "An RTP payload for MIDI"[1]. En 2006, le document a été soumis à l'IETF et a reçu le numéro RFC4695[2]. En parallèle, un autre document fut écrit par Lazzaro et Wawrzynek pour donner les détails à propos de l'implémentation pratique du protocole RTP-MIDI, notamment le mécanisme de journalisation[3].

RFC4695 a été rendue obsolète par RFC6295 en 2011 (le protocole entre les deux documents n'a pas été modifié. La seconde version contient juste la correction des erreurs trouvées dans RFC4695)[4]

Le MMA (MIDI Manufacturers Association), qui centralise toutes les normes et recommandations liées aux implémentations ouvertes du système MIDI, a créé une page sur son site destinée à fournir les informations de base liées au protocole RTP-MIDI[5]. Un site central d'informations (visant les utilisateurs comme les programmeurs) a également été créé afin de répondre plus en détail aux questions liées à RTP-MIDI[6].

L'implémentation RTP MIDI de Apple (AppleMIDI)[modifier | modifier le code]

Apple Computers a introduit RTP-MIDI directement dans son système d'exploitation Mac OS X v10.4 en 2005. Le pilote RTP-MIDI est accessible à travers l'icône Réseau MIDI dans l'outil Configuration MIDI/Audio (dans le dossier Utilitaires). L'implémentation Apple suit strictement la spécification RFC4695/RFC6295 pour la charge RTP et le système de journalisation, mais utilise un système différent pour la gestion de protocole. Ce protocole est décodé dans Wireshark sous le nom "AppleMIDI".

Apple a également créé une classe spécifique dans leur implémentation mDNS (connue sous le nom "Bonjour"). Les appareils conformes à cette classe apparaissent automatiquement dans le panneau de configuration RTP-MIDI d'Apple, sous la forme d'un répertoire de participants, rendant ainsi le système AppleMIDI entièrement "Plug & Play". Il est toutefois possible d'entrer directement des adresses IP et des numéros de ports dans ce répertoire, afin de connecter des appareils qui ne supportent pas Bonjour.

Apple a également implémenté RTP-MIDI dans iOS4 et les versions suivantes, mais les appareils utilisant ce système d'exploitation ne peuvent pas devenir des initiateurs de sessions. Ils nécessitent donc un appareil ou un logiciel externe implémentant la fonction "Initiateur de session".

Le pilote RTP-MIDI d'Apple crée des ports MIDI virtuels (appelés "Sessions") qui deviennent disponibles comme une paire de port MIDI IN / MIDI OUT standards dans n'importe quel logiciel utilisant CoreMIDI (comme des séquenceurs ou des instruments virtuels), comme n'importe quel autre port MIDI 1.0 ou USB.

Implémentation embarquée de RTP-MIDI[modifier | modifier le code]

En 2006, la société néerlandaise KissBox a présenté les premières implémentations embarquées de RTP-MIDI, dans des produits comme des interfaces MIDI ou LTC[7]. Un pilote de périphériques propriétaires pour Windows XP avait été développé par la société, mais ce pilote limitait la communication avec leurs appareils (il n'était pas possible de connecter un PC avec un Mac par exemple en utilisant ce pilote). Néanmoins, les appareils eux-mêmes sont totalement conformes à l'implémentation AppleMIDI (utilisation du même protocole de gestion de sessions), et peuvent être utilisés avec les pilotes Apple sous Mac OS-X et rtpMIDI sous Windows. À la suite de la mise à disposition du pilote ouvert rtpMIDI de Tobias Erichsen, le support du pilote propriétaire a été abandonné, afin de développer une plateforme totalement homogène.

KissBox a annoncé en le développement d'un logiciel nommé "RTP-MIDI Editor", destiné à gérer dynamiquement les sessions entre les appareils et logiciels RTP-MIDI d'un réseau depuis un point central. Cette annonce a été suivie du lancement d'une nouvelle CPU (nommée « V3 »), capable de devenir un initiateur de session, permettant d'établir une connexion avec d'autres appareils sans nécessiter la présence d'un ordinateur. Cette possibilité permet notamment d'utiliser la CPU en tant qu'interface MIDI pour les appareils sous iOS qui ne disposent pas de la capacité de devenir des initiateurs de session.

Durant le NAMM 2013, la société iConnectivity (Canada) a présenté une interface de 4 ports MIDI In/Out avec connexion réseau Ethernet basée sur RTP-MIDI[8].

Le constructeur américain Mackie propose une famille de tables de mixages dont l'interface utilisateur est réalisée par un iPad[9]. Ces tables de mixage intègrent une liaison RTP-MIDI sur Ethernet, permettant d'utiliser jusque 10 iPad en réseau Wi-Fi pour la commande à distance.

Pilote RTP-MIDI pour Windows[modifier | modifier le code]

Tobias Erichsen a mis sur le marché en 2010 une version pour Windows du pilote RTP-MIDI d'Apple[10]. Ce pilote fonctionne sous Windows XP, Windows Vista, Windows Seven et Windows 8, pour les versions 32 et 64 bits. Ce pilote utilise un panneau de configuration similaire à celui d'Apple, et est totalement compatible avec l'implémentation Apple. Il peut donc être utilisé pour connecter une machine Windows avec un ordinateur Macintosh ou des systèmes RTP-MIDI embarqués (claviers, synthétiseurs, consoles de mixage, etc.) Comme son homologue d'Apple, le pilote Windows crée des ports MIDI virtuels, qui deviennent disponibles pour n'importe quel logiciel fonctionnant sur le PC (l'accès se faisant au travers de la couche logicielle mmsystem, comme pour n'importe quel autre port MIDI sous Windows).

RTP-MIDI sur Linux[modifier | modifier le code]

Les premiers travaux de portage du protocole RTP-MIDI sous Linux ont été réalisés par Nicolas Falquet et Dominique Fober, de l'institut GRAME[11],[12]. Ces travaux visaient initialement la création d'un pilote système OSS. Une implémentation complète (y compris le système de journalisation) de RTP-MIDI est disponible sur la distribution Ubuntu dans la suite logicielle Scenic[13]. Un daemon RTP-MIDI pour le serveur JACK, appelé jackrtpmidid et spécifiquement compilé pour Linux, est annoncé pour le synthétiseur Open Source Zynthian[14].

RTP-MIDI sous Javascript[modifier | modifier le code]

Une implémentation du protocole RTP-MIDI sous Javascript a été mise en ligne sur Github par J.Dachtera en [15]. Cette implémentation utilise le protocole de session décrit par Apple, et peut agir en tant que "Session initiator" et en tant que "Session listener"

RTP-MIDI sous Java[modifier | modifier le code]

La bibliothèque NMJ[16] permet une implémentation multiplateformes de RTP-MIDI sous Java.

RTP-MIDI sous WinRT pour applications Windows Store[modifier | modifier le code]

Le projet WinRTP-MIDI[17] propose une implémentation open-source de la pile de protocole RTP-MIDI sous Windows. Initialement prévue pour être portable sous les différentes versions de Windows, la bibliothèque est maintenant optimisée pour être utilisée sous WinRT en vue de simplifier le développement d'applications pour le Windows Store.

RTP-MIDI dans les groupes « Open Source » (Arduino / MIDIBox / Axoloti)[modifier | modifier le code]

En , deux membres de la communauté MIDIBox ont commencé à travailler sur l'intégration du protocole RTP-MIDI dans une nouvelle version du logiciel MIOS (MIDIBox Operating System), à travers un lien SPI (Serial Peripheral Interconnect) rapide. Afin de simplifier l'intégration, il a été décidé d'utiliser une carte de communication réseau externe chargée de la pile de protocole complète. Une première version "beta" a été diffusée début [18]. La première version officielle du logiciel a été diffusée durant la première semaine de .

Le protocole utilisé sur le lien SPI entre le processeur MIOS et le processeur réseau est basé sur le même format que les télégrammes MIDI sur USB (utilisation de mots 32 bits contenant un message MIDI complet) et a été proposé comme standard ouvert pour la communication entre processeurs réseaux et carte d'applications MIDI.

RTP-MIDI a été inclus dans la plateforme ouverte Arduino en (sous le nom "AppleMIDI library")[19]. Le module logiciel peut fonctionner sur les cartes Arduino disposant d'une interface Ethernet native, ou à travers le "Shield Ethernet" (un "shield" est une carte d'extension dans la terminologie Arduino). La bibliothèque RTP-MIDI ne nécessite pas un "shield" spécialisé, contrairement aux protocoles propriétaires.
Une autre solution pour la communauté Arduino a été présentée dans une note d'application publiée par la société KissBox pour leur module RTP-MIDI OEM. Cette solution est similaire à celle utilisée par la communauté MIDIBox (processeur externe de communication, connecté via un bus SPI rapide). Cette solution permet l'utilisation de cartes Arduino avec une quantité de RAM très limitée, telles que l'Arduino Uno, et permet de libérer complètement le processeur local pour l'utilisateur, car le module externe implémente l'intégralité de la pile de communication et agit comme tampon mémoire de stockage entre le réseau et l'Arduino.

La communication RTP-MIDI est également disponible pour le synthétiseur matériel Axoloti à travers le bloc logiciel "Axoloti-RTP"[20]. La carte Axoloti peut également être équipée d'un coprocesseur de communication RTP-MIDI via le bus SPI disponible sur le connecteur d'extension, selon le même principe que la solution disponible sur les plateformes Arduino et MIDIBox.

Utilisation de RTP-MIDI sans pilote[modifier | modifier le code]

Comme RTP-MIDI est basée sur la pile de protocole standard UDP/IP, n'importe quelle application peut implémenter le protocole directement sans nécessiter un pilote de couche basse. Ces pilotes ne sont en fait nécessaires que lorsque l'on veut faire apparaître les ports MIDI du réseau RTP-MIDI comme des ports MIDI standards dans des logiciels. Des objets (« Externals ») pour Max/MSP et des plugins VST ont été développés suivant cette méthode et sont disponibles depuis le milieu de l'année 2012.

RTP-MIDI sur les réseaux AVB[modifier | modifier le code]

AVB est un ensemble de normes techniques qui définissent les spécifications pour la diffusion de flux audio/vidéo (« streaming ») sur réseau Ethernet avec des latences extrêmement faibles. Les réseaux AVB sont capables de tenir des latences aussi faibles qu'un seul échantillon audio (soit 20 microsecondes pour des flux audio à 48kHz) sur l'ensemble du réseau.

RTP-MIDI est compatible d'office avec n'importe quel réseau AVB, car les commutateurs réseau AVB (également connus sous le nom de « commutateurs IEEE802.1 ») gèrent automatiquement les priorités entre les flux audio/vidéo temps-réel et le trafic IP.

Toutefois, le protocole RTP-MIDI peut également bénéficier des possibilités temps-réel d'AVB si l'appareil implémente les messages RTCP décrits dans le document IEEE-1733[21]. Les applications RTP-MIDI peuvent alors corréler l'horloge de « présentation » (fournie par l'horloge Maître IEEE-802.1) avec l'indicateur temporel RTP, garantissant une distribution précise à l'échantillon près des messages MIDI.

Éléments du protocole RTP-MIDI[modifier | modifier le code]

Les documents RFC4695/RFC6295 découpent le système RTP-MIDI en différents sous-éléments. Le seul élément obligatoire (qui définit la conformité en tant que telle au protocole) est le format de la charge utile du télégramme. Le système de journalisation est optionnel (mais les messages RTP-MIDI doivent indiquer dans tous les cas qu'ils contiennent un journal, qui sera alors vide si la journalisation n'est pas activée) La partie liée au contrôle/gestion des sessions est quant à elle purement informative (et n'a d'ailleurs pas été utilisée par Apple, qui a créé son propre protocole de gestion de sessions)

Format des paquets RTP-MIDI[modifier | modifier le code]

Format des paquets RTP-MIDI
Section Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
RTP 0 V P X CC M Identificateur de type RTP (PT) Numéro de séquence
32 Marqueur temporel (Timestamp)
64 Identifiant de source de synchronisation (SSRC)
96 Identifiants des sources contributrices (CSRC) (optionnels)
… …
Commandes MIDI … B J Z P LEN… Liste des messages MIDI…
Journal (optionnel, dépend du bit J) … S Y A H TOTCHAN Numéro de séquence du paquet de contrôle Journal "system" (optionnel)…
Journaux des canaux…

Protocole de session Apple[modifier | modifier le code]

Le document RFC6295 propose l'utilisation des protocoles SDP (Session Description Protocol) et SIP (Session Initiation Protocol) pour l'établissement et la gestion des sessions entre partenaires RTP-MIDI. Néanmoins, ces deux protocoles sont relativement lourds à implémenter sur les petits systèmes, d'autant qu'ils n'imposent aucune contrainte au niveau des paramètres énumérés dans la description de session (notamment la fréquence d'échantillonnage de laquelle dépendent tous les champs relatifs aux informations temporelles tant au niveau de l'en-tête RTP que de la charge RTP-MIDI). De plus, le document RFC6295 se limite à une proposition de protocole, autorisant l'utilisation de tout autre protocole, amenant à autant de situations potentielles d'incompatibilité entre fournisseurs.

Apple a donc décidé de créer son propre protocole de session, en imposant les paramètres relatifs à la synchronisation, notamment la fréquence d'échantillonnage. Ce protocole de session est appelé "AppleMIDI" dans le logiciel Wireshark. La gestion des sessions avec le protocole AppleMIDI nécessite deux ports UDP, l'un appelé "Port de contrôle", l'autre appelé "Port de données". Dans le cas d'une implémentation multi-threads, seul le port de données nécessite un thread à caractéristique temps-réel, l'autre port peut être géré par un thread de priorité plus faible. Ces deux ports doivent être placés sur deux numéros de ports consécutifs (n / n+1), le premier d'entre eux pouvant utiliser n'importe lequel des 65536 ports possibles d'une machine.

Il n'existe aucune contrainte quant au nombre de sessions pouvant être ouvertes simultanément sur un couple de ports UDP pour le protocole AppleMIDI. On peut donc soit créer autant de couples de ports qu'il y aura de gestionnaires de session dans un système, soit utiliser un couple unique pour plusieurs sessions (ce qui limitera d'autant l'empreinte mémoire dans un système). Dans ce dernier cas, la pile IP permet d'identifier le partenaire à partir de son adresse IP et de ses numéros de port (cette fonction est appelée "réutilisation des sockets" et est disponible dans la plupart des implémentations IP actuelles)

Tous les messages du protocole AppleMIDI utilisent une structure commune formée de 4 mots de 32 bits, dont l'en-tête contient deux octets contenant tous deux la valeur 255, suivi de deux octets représentant la fonction désirée:

Description Définition dans Wireshark Code hexadécimal Caractères
Invitation APPLEMIDI_COMMAND_INVITATION 0x494e IN
Invitation acceptée APPLEMIDI_COMMAND_INVITATION_ACCEPTED 0x4f4b OK
Invitation refusée APPLEMIDI_COMMAND_INVITATION_REJECTED 0x4e4f NO
Fermeture de session APPLEMIDI_COMMAND_ENDSESSION 0x4259 BY
Synchronisation d'horloge APPLEMIDI_COMMAND_SYNCHRONIZATION 0x434b CK
Synchronisation du journal APPLEMIDI_COMMAND_RECEIVER_FEEDBACK 0x5253 RS
Contrôle de bande passante APPLEMIDI_COMMAND_BITRATE_RECEIVE_LIMIT 0x524c RL

Ces différents messages commandent une machine d'état propre à chaque session (cette machine d'état interdit par exemple l'échange de données MIDI tant qu'une session n'est pas passée en état "ouvert")

Séquence d'invitation[modifier | modifier le code]

Toute ouverture démarre par une séquence d'invitation. Le premier partenaire ("Session Initiator") envoie un message IN vers le port de contrôle du second partenaire. Ce dernier répond alors soit par un message OK s'il accepte d'ouvrir la session, soit par un message NO s'il refuse. La même séquence se répète ensuite sur le port de données, afin de vérifier que le second partenaire est totalement prêt. Une fois la séquence d'invitation exécutée, la machine d'état passe en phase de synchronisation

Séquence de synchronisation[modifier | modifier le code]

La séquence de synchronisation permet aux deux participants d'une session préalablement ouverte de partager leurs informations relatives aux horloges locales. Cette phase permet de corriger les latences introduites par le réseau, ainsi que de permettre au récepteur d'un message MIDI de déterminer s'il doit être transmis immédiatement ou de façon décalée (voir le chapitre Latence ci-dessous)

L'initiateur de session transmet un premier message (appelé CK0) vers le partenaire distance, indiquant sur 64 bits son heure locale (Remarque : il ne s'agit pas d'une "heure" absolue, mais d'une heure liée à une référence locale, généralement exprimée en microsecondes depuis le démarrage du noyau du système d'exploitation). Cette heure est exprimée sur la base d'une horloge à 10 kHz (100 microsecondes par incrément) Le partenaire distant doit répondre à ce message en renvoyant sa propre heure locale sur 64 bits par un message CK1. Les deux partenaires connaissent alors la différence entre leurs deux horloges locales et peuvent déterminer le décalage à appliquer sur les champs Timestamp et DeltaTime du protocole RTP-MIDI. L'initiateur de session termine alors cette séquence en renvoyant un dernier message appelé CK2, qui indique la nouvelle heure locale à la réception du message CK1. Cette technique permet d'une part de déterminer la valeur moyenne de la latence créée par le réseau, et de compenser un éventuel décalage accidentel dû à un retard de traitement par un thread (situation pouvant survenir avec les systèmes d'exploitation non-temps réel comme Linux, Windows ou OS X)

Apple recommande de répéter plusieurs fois cette séquence juste après l'ouverture de session afin d'augmenter encore plus la précision de la synchronisation (au cas où l'une des séquences de synchronisation aurait été accidentellement allongée en raison d'une surcharge temporaire du réseau ou d'une pointe de latence au réveil d'un thread)

Cette séquence doit se répéter cycliquement (entre 2 et 6 fois par minute généralement), systématiquement à l'initiative de l'initiateur de session, d'une part pour maintenir la précision de synchronisation à long terme et corriger les dérives des horloges locales, d'autre part pour détecter l'éventuelle perte du partenaire distant. La non-réponse d'un partenaire distant à plusieurs messages CK0 consécutifs est considérée comme une déconnexion accidentelle. Dans la plupart des cas, les initiateurs de session basculent alors leur machine d'état en mode "Invitation" afin de réactiver la communication automatiquement dès la reconnexion du partenaire distant. Certaines implémentations (notamment sur les ordinateurs personnels) affichent un message d'alerte et proposent à l'utilisateur de choisir entre une nouvelle tentative de connexion ou la fermeture de la session.

Mise à jour du journal[modifier | modifier le code]

Le mécanisme de journalisation permet à un récepteur RTP-MIDI de détecter la perte d'un message sur le réseau et de générer automatiquement les données MIDI manquantes sans nécessiter de retransmission. Ce journal garde en mémoire des "images" de l'état MIDI entre les différents partenaires à un instant donné. Il est inutile de conserver en mémoire un journal correspondant à des événements reçus correctement par un partenaire. Chaque partenaire envoie donc cycliquement vers l'autre partenaire un message RS indiquant le numéro de séquence du dernier message RTP-MIDI reçu correctement sans désynchronisation (en d'autres termes, dont tous les numéros de séquence sont consécutifs). L'émetteur peut donc, si besoin, libérer la mémoire correspondante aux données journalisées antérieures à ce message.

Déconnexion d'un partenaire[modifier | modifier le code]

Un partenaire de session peut demander à quitter la session à tout moment, entrainant la fermeture de celle-ci. Cette demande de déconnexion se fait par le message BY. La réception de ce message par l'un des partenaires entraine la fermeture immédiate de la session et la libération éventuelle des ressources allouées pour cette session. À noter que ce message peut être envoyé par l'initiateur de session comme par le partenaire distant ("invité").

Latence[modifier | modifier le code]

La préoccupation la plus fréquente concernant RTP-MIDI est la latence (et qui est d'ailleurs le sujet de discussion le plus fréquent dès lors que l'on parle des stations de travail audionumériques modernes), principalement en raison de l'utilisation des piles logicielles IP des ordinateurs. Il est toutefois très facile de démontrer qu'un logiciel RTP-MIDI (application ou pilote) ne produit pas plus de latence qu'une autre méthode de communication.

Qui plus est, le protocole RTP-MIDI tel que décrit dans RFC6295 comporte un mécanisme de compensation de la latence. Un système similaire existe dans la plupart des plugins audionumériques, qui peuvent informer leur hôte de la latence qu'ils ajoutent sur le chemin du signal audio. L'hôte peut alors envoyer les échantillons au plugin en avance, de façon que ceux-ci soient prêts et disponibles de façon synchrone avec les autres flux audio. Le mécanisme décrit dans RFC6295 utilise un système de marquage temporel (timestamp) relatif, basé sur le système MIDI appelé « deltatime » (tel que décrit dans[22]). Chaque événement MIDI transporté dans le message RTP comporte un champ de marquage temporel, dont la référence est donnée par le champ « Timestamp » de l'en-tête RTP.

Chaque événement MIDI transporté sur RTP-MIDI peut donc être précisément synchronisé avec l'horloge globale. La précision de la synchronisation dépend directement de la source d'horloge définie lors de l'ouverture de la session RTP-MIDI. Le document RFC6295 donne plusieurs exemples basés sur une horloge d'échantillonnage audio, afin d'obtenir une précision à l'échantillon près de chaque événement MIDI. L'implémentation d'Apple (ainsi que toutes celles qui en sont dérivées comme le pilote rtpMIDI pour Windows ou les systèmes KissBox) utilisent une horloge à une fréquence fixe de 10 kHz plutôt qu'une fréquence d'échantillonnage audio. La précision temporelle de tous les événements MIDI est donc de 100 microsecondes pour ces implémentations. Les horloges des émetteurs et récepteurs sont synchronisées lors de l'ouverture de la session, et sont maintenus synchronisés de façon cyclique par les initiateurs de sessions. Ce mécanisme a la capacité de compenser n'importe quelle latence, de quelques centaines de microsecondes (comme sur les applications LAN) jusque plusieurs secondes (ce qui le rend capable de compenser des latences telles que rencontrées sur Internet, rendant ainsi possible l'exécution en temps réel de morceaux de musique entre deux machines connectées via Internet)

Ce mécanisme est toutefois principalement conçu pour les flux MIDI pré-enregistrés, tels que ceux produits par une piste de séquenceur. Quand RTP-MIDI est utilisé pour les applications temps-réel, (par exemple, pour contrôler des appareils depuis un clavier de commande compatible RTP-MIDI[23]), le champ « deltatime » est le plus souvent mis à 0, ce qui indique que l'événement MIDI qui lui est attaché doit être interprété dès qu'il a été reçu. Le système de compensation de latence décrit ci-dessus ne peut alors pas être utilisé.

La latence obtenue pour ces applications temps-réel est directement dépendante des différents éléments logiciels et matériels du réseau qui se trouvent sur le chemin entre les appareils RTP-MIDI, à savoir:

  • temps de traitement du logiciel MIDI
  • temps de traitement de la pile logicielle IP
  • temps de propagation à travers les routeurs/commutateurs réseau (« switches »)

Temps de traitement du logiciel MIDI[modifier | modifier le code]

Le temps de traitement des logiciels MIDI (séquenceurs, plugins, etc.) est normalement contrôlé précisément, les tâches qui y sont liées étant le plus souvent de type temps-réel ou "time-critical". Dans la plupart des cas, la latence de l'application est liée à celle du thread le plus rapide pouvant être obtenu sur un système d'exploitation donné (de 1 à 2 ms sur des Windows ou Mac OS. Les noyaux temps-réel peuvent donner quant à eux des résultats bien meilleurs, typiquement de l'ordre de 100 microsecondes). Ce temps de traitement peut être considéré comme constant quel que soit le support de transmission (MIDI 1.0, USB, RTP-MIDI, etc.), car les threads applicatifs tournent normalement sur un niveau différent de ceux liés aux tâches de communication.

Temps de traitement de la pile logicielle IP[modifier | modifier le code]

Le temps de traitement lié à la pile IP est le plus critique, car le process de communication passe alors sous le contrôle exclusif du système d'exploitation. Ceci s'applique à tous les protocoles de communication (liés à IP ou non), car la plupart des systèmes d'exploitation (y compris Windows, Mac OS ou Linux) interdisent les accès directs aux cartes réseau Ethernet. En particulier, une erreur courante est la confusion entre les « raw sockets » et un accès direct au matériel (les sockets étant le point d'échange avec le système d'exploitation des données transmises et reçues sur le réseau). Un "raw socket" (comme ceux qui devaient être utilisés pour le protocole IEEE-P1639) est juste un socket qui autorise un logiciel à envoyer n'importe quel télégramme avec n'importe quel protocole (le logiciel étant alors responsable du respect des règles liées au protocole utilisé). Un accès direct aux cartes réseau impliquerait un accès bas niveau, réservé aux pilotes et au noyau du système d'exploitation. Un télégramme envoyé via un raw socket peut donc être retardé comme n'importe quel autre télégramme par le système d'exploitation si la carte réseau visée est déjà en cours d'utilisation par un autre logiciel. Par conséquent, un paquet IP peut parfaitement être envoyé avant un paquet transmis par un raw socket (techniquement parlant, ces accès aux cartes réseaux sont gérés par des sémaphores, sous le contrôle exclusif du système d'exploitation[24].

Les piles IP nécessitent également de corréler les adresses physiques Ethernet (adresses MAC) avec les adresses IP, en utilisant un protocole spécifique appelé ARP. Quand un logiciel RTP-MIDI veut envoyer un télégramme à un appareil distant, il doit d'abord localiser ce dernier sur le réseau (Ethernet ne sachant interpréter les concepts propres à IP), afin de créer le chemin de transmission à travers les routeurs et les commutateurs réseau. Cette opération est effectuée automatiquement par la pile IP qui va envoyer d'abord une requête ARP (Address Recognition Protocol). Quand le destinataire reconnaît sa propre adresse IP dans le paquet ARP, il va envoyer automatiquement une réponse ARP avec sa propre adresse MAC. La pile IP va alors pouvoir envoyer les télégrames RTP-MIDI sur le réseau. Les messages RTP-MIDI suivants n'ont en revanche pas besoin de faire appel à la séquence ARP (sauf si les liens Ethernet deviennent inactifs pour plusieurs minutes, ce qui efface alors automatiquement les tables de routage de l'émetteur. Cette situation ne peut cependant pas se produire avec l'implémentation Apple qui maintient les tables de routage actives en effectuant toutes les minutes un cycle de synchronisation complet)

La séquence ARP peut prendre quelques secondes, selon la taille du réseau, ce qui pourra produire en retour une latence importante, au moins pour le premier paquet RTP-MIDI. L'implémentation Apple a résolu ce problème de façon élégante, en utilisant le protocole de contrôle de sessions. En effet, le protocole de session utilise les mêmes ports que le protocole RTP-MIDI. La séquence ARP a lieu donc pendant la phase d'établissement de session, avant même que les premiers échanges RTP-MIDI n'aient lieu. Quand l'application RTP-MIDI veut envoyer le premier paquet RTP-MIDI, les tables de routage de l'ordinateur sont déjà initialisées avec les bonnes adresses MAC, ce qui évitera toute latence pour le premier télégramme.

Parallèlement à la séquence ARP, la pile IP doit effectuer un certain nombre de calculs pour préparer les en-têtes des télégrammes (en-têtes IP, UDP et RTP). Cette préparation est cependant extrêmement rapide avec les processeurs modernes et ne prend que quelques microsecondes, ce qui est négligeable comparé à la latence de l'application elle-même. Comme décrit précédemment, une fois préparé, un télégramme RTP-MIDI ne peut plus être retardé que lorsqu'il sera transmis à la carte réseau si cette dernière est déjà en train de transmettre un autre message (et ce, que le socket soit de type IP ou raw). Toutefois, la latence introduite à ce niveau est normalement extrêmement faible car les threads des pilotes responsables des cartes réseau ont le plus souvent une priorité maximale. De plus, la plupart des cartes réseau actuelles ont des files d'attente de type FIFO au niveau matériel, permettant de stocker les télégrammes en attente d'émission, qui seront alors transmis à la suite, sans nécessiter d'intervention du logiciel. La meilleure solution pour garder la latence due à l'arbitrage d'accès la plus faible possible est tout simplement de réserver une carte réseau pour la communication RTP-MIDI, et d'en utiliser une autre pour les utilisations du type échange de fichiers ou navigation sur Internet.

Temps de propagation à travers les routeurs/commutateurs réseau (« switches »)[modifier | modifier le code]

Les différents composants matériels utilisés pour la transmission des télégrammes Ethernet entre les ordinateurs (quel que soit le protocole utilisé) introduisent également de la latence. Tous les commutateurs réseau modernes utilisent la technique "store and forward", dans laquelle les télégrammes sont reçus entièrement et stockés dans le switch, avant d'être envoyé vers les switches suivants. Toutefois, les temps de commutation ainsi introduits sont négligeables (un télégramme de 64 octets sur un réseau 100 Mbit/s prend environ 5,1 microsecondes pour traverser un commutateur. Un réseau complexe qui aurait 10 commutateurs sur un chemin donné n'introduit donc qu'une latence de 51 microsecondes)

Le principal facteur reste la charge transmise sur le réseau, car les commutateurs ne transmettent des paquets vers les commutateurs suivants que lorsque le lien vers celui-ci devient disponible. Il en résulte que le calcul de la latence réellement introduite par les composants du réseau peut être une tâche ardue, et doit prendre en compte les contextes réels d'utilisation (Ainsi, la mesure de la latence et de la gigue de phase entre deux appareils connectés au même commutateur et ne communiquant qu'entre eux donnera toujours d'excellents résultats, quel que soit le protocole). Comme indiqué dans le paragraphe précédent, la meilleure solution ici encore pour limiter la latence est d'utiliser des réseaux séparés entre les données critiques en temps, et les autres. Toutefois, ce requis est beaucoup moins critique pour les commutateurs réseau que pour les cartes réseau. Cette solution ne serait à considérer que dans le cas de réseaux de très grande taille, connectant de très nombreux systèmes, utilisant une grande partie de la bande passante.

Latence attendue selon les cas pratiques[modifier | modifier le code]

Comme on peut le voir, la latence que l'on peut attendre sur un système RTP-MIDI dépend de nombreux paramètres, la plupart étant d'ailleurs liés aux systèmes d'exploitation avant tout. Ce point est d'ailleurs valable quel que soit le protocole utilisé. Des mesures effectuées par les différents acteurs utilisant RTP-MIDI donnent des temps de latence entre quelques centaines de microsecondes entre systèmes embarqués basés sur des noyaux temps-réel, jusque 3 millisecondes lorsque des ordinateurs avec systèmes d'exploitation générique (Linux, Windows, Mac OS...) sont impliqués.

Configuration[modifier | modifier le code]

La seconde préoccupation la plus fréquente concernant RTP-MIDI est le processus de configuration, car la connexion physique d'un appareil à un réseau n'est pas suffisante pour assurer une communication avec un autre appareil connecté au même réseau. Comme RTP-MIDI est basé sur une pile de protocole IP, les différentes couches impliquées dans le processus de communication doivent être configurées (configuration de l'adresse IP et des ports UDP à minima). Afin de simplifier cette étape, différentes solutions ont été proposées, la plus connue étant le groupe de technologies "Zero Configuration", également connue sous le nom "Zeroconf".

Le document RFC3927[25] décrit une technique répandue d'assignation automatique d'adresse IP, utilisée par la plupart des appareils compatibles RTP-MIDI sur le marché. Une fois connecté au réseau, un tel appareil est capable de s'attribuer seul une adresse IP, avec résolution automatique des éventuels conflits d'adresses. Si le même appareil suit les recommandations de la spécification RTP quant au choix des numéros de port UDP, il devient totalement "Plug&Play" du point de vue du réseau. Il est alors possible de créer un réseau RTP-MIDI sans avoir à définir les adresses IP et/ou les numéros de ports UDP. Il faut cependant souligner que ces méthodes sont souvent réservées aux petites installations. L'automatisation complète de la configuration est souvent évitée sur les grosses installations, car la localisation physique des appareils peut devenir complexe (pour le dépannage par exemple), par suite de l'absence de corrélation entre l'adresse sélectionnée automatiquement et la position réelle des appareils. Une configuration « à minima » serait alors d'assigner un repère ou un nom à l'appareil avant de le connecter au réseau, entrainant de fait la suppression du caractère « Plug&Play » de l'installation dans ce cas.

Il faut également noter que le concept « Zéro Configuration » se limite aux couches de communication. Il est techniquement impossible de réaliser l'installation complète d'un appareil connecté à un réseau (qu'il soit lié au MIDI ou non) juste par abstraction de la couche d'adressage. Un exemple pratique qui démontre cette limitation serait un générateur de sons contrôlé à distance par un clavier maître connecté à une interface MIDI sur réseau. Même si le générateur de sons et l'interface MIDI intègrent des services "Zero Configuration", ils sont incapables de déterminer par eux-mêmes qu'ils doivent établir une session commune pour échanger des données MIDI, car les services de configuration automatique n'agissent pas sur le niveau applicatif. Tout système MIDI basé sur un réseau, quel que soit le protocole utilisé pour échanger les données MIDI (qu'il soit compatible RTP-MIDI ou non) impose l'utilisation d'un outil de configuration afin de définir les échanges qui devront avoir lieu entre les appareils après leur connexion au réseau. Cet outil de configuration pourra être un logiciel externe qui s'exécute sur un ordinateur chargé de la gestion de l'installation, ou être directement intégré au logiciel applicatif d'un appareil (par exemple, sous la forme d'un menu accessible par l'interface Homme-Machine).

Sociétés/projets utilisant le protocole RTP-MIDI[modifier | modifier le code]

  • Apple Computers (Pilote RTP-MIDI intégré dans Mac OS X et iOS pour l'ensemble de leurs produits) - RTP-MIDI sur Ethernet et Wi-Fi
  • Yamaha (Synthétiseurs Motif, applications iOS de commande à distance[26], adaptateur Wi-Fi UD-WL01[27])
  • Behringer (Surface de contrôle XTouch)[28]
  • KissBox (Interfaces RTP-MIDI pour systèmes MIDI 1.0, LTC, Entrées/Sorties et DMX, plugins VST pour commande à distance de synthétiseurs matériels)
  • Tobias Erichsen (Utilitaires et pilote RTP-MIDI pour Windows)
  • GRAME (pilote pour Linux)
  • HRS (Distribution de code temporel MIDI sur Ethernet / Logiciels de synchronisation)
  • iConnectivity (interfaces MIDI)
  • Zivix PUC (Interface MIDI sans fil pour iOS)[29]
  • Mackie (Tables de mixage DL1608/DL806 pilotées par iPad)
  • Arduino[30]
  • MIDIBox[31]
  • Cinara (Interface MIDI USB/RTP-MIDI)[32]
  • BEB Digital Audio (Applications iOS compatibles RTP-MIDI)[33]
  • Axoloti (Synthétiseur "patchable" open source)[34]
  • Zynthian ("Open Synth Platform")[35],[14]

Compatibilité avec MIDI 2.0[modifier | modifier le code]

L'association MMA (MIDI Manufacturers Association) a annoncé en qu'une évolution majeure du protocole MIDI, appelée MIDI 2.0 entrait en phase de prototypage[36].

MIDI 2.0 s'appuie sur l'extension MIDI-CI (officialisée en ), qui est utilisée pour la négociation du protocole (identification des appareils MIDI 1.0 et MIDI 2.0 pour permettre le choix entre les deux protocoles). RTP-MIDI est entièrement compatible nativement avec le protocole MIDI-CI, ce dernier utilisant le protocole System Exclusive basé sur MIDI 1.0, même sur les appareils MIDI 2.0.

Une évolution du protocole RTP-MIDI pour inclure les paquets propres à MIDI 2.0 a été présentée au MMA pour être évaluée par les membres du groupe de travail. Le protocole évolué permet l'échange simultané des données au format MIDI 1.0 et MIDI 2.0 (MIDI 2.0 utilise des paquets formés de mots de 32 bits, alors que MIDI 1.0 utilise des paquets codés sur la base d'un octet)

Références[modifier | modifier le code]

  1. ↑ An RTP Payload format for MIDI. The 117th Convention of the Audio Engineering Society, October 28-31, 2004, San Francisco, CA.
  2. ↑ RTP Payload format for MIDI - RFC4695
  3. ↑ Implementation Guide for RTP MIDI. RFC 4696
  4. ↑ RTP Payload format for MIDI - RFC6295
  5. ↑ [1] Page 'A propos' du MIDI Manufacturers Association
  6. ↑ rtp-midi.com site http://www.rtp-midi.com
  7. ↑ Site de la société Kiss-Box (appareils utilisant le protocole RTP-MIDI)
  8. ↑ (en) NAMM : iConnectivity lance deux interfaces MIDI synthtopia.com, janvier 2013
  9. ↑ « DL1608 », sur Mackie, (consulté le ).
  10. ↑ [2] Pilote RTP-MIDI pour Windows
  11. ↑ (en) http://www.grame.fr/ressources/publications/falquet05.pdf Implementing a MIDI stream over RTP
  12. ↑ (en) http://www.grame.fr/ressources/publications/TR-050622.pdf Recovery journal and evaluation of alternative proposal
  13. ↑ http://manpages.ubuntu.com/manpages/oneiric/man1/midistream.1.html#contenttoc0 Page de manuel pour l'objet RTP-MIDI midistream sous Linux Ubuntu
  14. ↑ a et b (en) « RTP-MIDI on zynthian », sur zynthian.org.
  15. ↑ « Jdachtera/node-rtpmidi », sur GitHub (consulté le ).
  16. ↑ « Nmj », sur humatic.de (consulté le ).
  17. ↑ [3] Site web du projet open-source WinRTP-MIDI
  18. ↑ Annonce du support de RTP-MIDI dans le système MIOS MIDIBox
  19. ↑ Bibliothèque RTP-MIDI/AppleMIDI pour Arduino
  20. ↑ 262588213843476, « Axoloti-rtp », sur Gist (consulté le ).
  21. ↑ [4] Standard IEEE pour les protocoles de transport de couche 3 pour les applications temporelles critiques sur les réseaux locaux
  22. ↑ MIDI 1.0 Specification - Section 4 - Standard MIDI Files
  23. ↑ http://www.cme-pro.com/en/partner.php Kit d'extension RTP-MIDI pour claviers CME
  24. ↑ http://en.wikibooks.org/wiki/Operating_System_Design/Processes/Semaphores Fonctionnement des sémaphores
  25. ↑ Automatic configuration of IPv4 Link-Local addresses - RFC3927
  26. ↑ « Apps - Yamaha - France », sur Yamaha.com (consulté le ).
  27. ↑ « Les Pianos - Yamaha - France », sur Yamaha.com (consulté le ).
  28. ↑ « behringer.com/EN/Products/X-TO… »(Archive.org • Wikiwix • Archive.is • Google • Que faire ?).
  29. ↑ (en) « The Legacy Wireless WiFi MIDI Product », sur Indiegogo (consulté le ).
  30. ↑ Page d'accueil Arduino
  31. ↑ Page d'accueil MIDIBox
  32. ↑ Site web de Cinara
  33. ↑ Site web de BEB Digital Audio
  34. ↑ Site web du système Axoloti
  35. ↑ (en) « Home », sur zynthian.org (consulté le ).
  36. ↑ (en) « The MIDI Manufacturers Association (MMA) and the Association of Music Electronics Industry (AMEI) announce MIDI 2.0™ Prototyping », sur The MIDI Association (consulté le ).
Ce document provient de « https://fr.wikipedia.org/w/index.php?title=RTP_MIDI&oldid=214678496 ».