Résumé

  • Une commande perdue peut provoquer une absence passagère ou dérégler durablement le rendu. Le journal de récupération vise les erreurs qui se prolongent, pas une relecture exhaustive des commandes manquantes.
  • Le récepteur rapproche son historique des informations transportées par le journal et émet des commandes correctrices. Une attaque devenue trop tardive peut rester volontairement silencieuse.
  • L'étendue de l'historique, l'initialisation des nouveaux participants et les paquets envoyés pendant les pauses limitent ce qui peut être réparé. Une spécification commune ne remplace ni les choix d'implémentation ni les contraintes du réseau.

Deux pertes, deux durées

Un premier paquet contenait l'ordre de faire sonner une note. Un second, dans un autre échange, contenait l'ordre de la terminer. Que chacun disparaisse, et le bilan de transport peut afficher la même perte. À l'écoute, pourtant, les conséquences divergent. Dans un cas, une note manque. Dans l'autre, une note risque de rester.

La distinction figurait déjà dans le RFC 4695, publié en novembre 2006. Le document séparait les défauts transitoires des défauts de durée indéfinie. L'absence d'une attaque ne dépasse normalement pas la durée prévue de la note. La disparition d'une commande NoteOff peut laisser un son se prolonger ; celle d'un réglage de volume peut fausser toutes les notes suivantes.

Ce sont des exemples de comportement, non le récit d'un concert interrompu. Une enveloppe sonore, une pédale ou une commande ultérieure peuvent modifier le résultat. Mais un protocole ne peut pas compter sur une correction accidentelle. Il doit distinguer ce qui finira avec l'événement de ce qui risque de s'installer dans l'instrument.

Voilà pourquoi la récupération ne pouvait pas être définie uniquement en paquets ou en octets. Il fallait également demander combien de temps une erreur resterait active.

L'instrument conserve ce que le réseau oublie

MIDI transporte des commandes symboliques : démarrer une note, l'arrêter, changer un programme ou un contrôleur. Il ne s'agit pas de morceaux d'une onde sonore déjà enregistrée. Un synthétiseur ou un logiciel produit le son à partir de ces commandes et de son état antérieur. La petite taille d'un message ne dit donc rien de la durée de ses effets.

RTP offrait un socle utile, mais pas la solution complète. Le RFC 3550, daté de juillet 2003, fournit notamment des numéros de séquence, des horodatages et des moyens de surveiller la réception. Il exclut explicitement toute garantie propre de livraison, de ponctualité ou d'ordre. Un numéro manquant peut révéler un trou ; il ne dit pas quel instrument continue à jouer trop fort.

Le format MIDI ajoute cette connaissance de l'application. Dans un flux utilisant le journal de récupération, les paquets emportent des informations sur l'historique pertinent. Après une perte, le récepteur compare ce qu'il sait déjà avec le journal du paquet qui met fin à l'interruption observée. Il peut alors exécuter des commandes locales pour corriger les différences.

Le RFC 6295, qui remplace le texte de 2006 en juin 2011, conserve le principe : le rendu ne doit pas comporter de défauts indéfinis dus à ces pertes. Il ne promet pas l'absence de tout accroc. La réparation transforme une erreur susceptible de durer en une perturbation limitée. Le passé reste imparfait ; l'avenir n'est plus obligé de lui ressembler.

Une mémoire de réparation, pas des archives de concert

Le journal ne repose pas sur la retransmission de chaque paquet disparu. Il décrit l'historique à partir d'un point de contrôle. Pour un paquet courant I et un point C, cet historique couvre les commandes de C à I−1, pas les nouvelles commandes de I. Le paquet présent apporte donc à la fois du nouveau et les éléments nécessaires pour corriger une partie de l'ancien.

Cette borne compte. La possibilité de récupérer la perte d'un nombre quelconque de paquets concerne ceux qui appartiennent à l'historique couvert. Elle ne signifie pas qu'une coupure de longueur arbitraire devient réparable. Le récepteur doit pouvoir vérifier que le point de contrôle remonte assez loin pour le trou qu'il a constaté.

La représentation est elle aussi sélective. Le chapitre N du journal traite les alternances habituelles entre NoteOn et NoteOff pour une hauteur donnée. Il ne conserve pas chaque attaque de toute la séance. Des répétitions superposées plus complexes nécessitent le soutien du chapitre E. Les exemples adaptés à un clavier ou à des pads ne suffisent pas à décrire toutes les suites produites par des contrôleurs de guitare ou d'instrument à vent.

Même le relâchement n'est pas toujours une opération acoustiquement simple. Une pédale peut maintenir un son malgré NoteOff. Or le journal ne permet pas nécessairement de reconstituer l'ordre exact entre ce relâchement et l'action sur la pédale. Lorsque son propre historique ne l'aide pas à trancher, le récepteur doit privilégier l'évitement d'un son maintenu à tort, quitte à introduire un défaut bref. La structure décrit ce qui est récupérable ; elle n'invente pas les détails perdus.

La note retrouvée qu'il vaut mieux ne pas jouer

Un journal NoteOn du chapitre N ne donne pas l'heure exacte de l'exécution originelle. Un bit Y indique plutôt s'il est recommandé de jouer ou de sauter la note. C'est un indice de décision, non une injonction de rejouer toute attaque mentionnée dans le passé.

Le RFC 4696, guide d'implémentation publié également en novembre 2006, présente un récepteur qui utilise cet indice et le retard du paquet. Il peut renoncer à produire une note tout en mettant à jour ses données de récupération comme si l'attaque avait été prise en compte. Ce choix prépare un traitement cohérent des commandes suivantes sans ajouter un son désormais mal placé.

Le guide montre aussi pourquoi un ancien paquet arrivé hors ordre peut devenir dangereux. Une correction a peut-être déjà été effectuée grâce au journal d'un paquet plus récent. Exécuter ensuite l'ancienne commande risque de doubler cette correction. Dans l'implémentation décrite, le paquet hors ordre est ignoré.

Il faut garder au guide son statut. C'est un document informatif et explicitement non normatif. Son exemple NMP suppose certaines caractéristiques de réseau, une sélection de commandes et l'absence de tampon de lecture. Le texte signale lui-même que cette dernière propriété ne satisfait pas entièrement une exigence d'interopérabilité qui demande la possibilité d'utiliser un tel tampon.

La règle normative n'impose donc pas cette unique méthode. Elle interdit au traitement d'un paquet hors ordre de créer un défaut indéfini. Un récepteur doté d'un tampon peut attendre le moment du rendu avant de réparer : le paquet supposé perdu peut encore arriver à temps. La liberté d'algorithme reste encadrée par le résultat à protéger.

Quand le silence retarde la découverte

Le guide de 2006 propose une autre scène révélatrice. Une commande NoteOff disparaît, puis le musicien ne produit rien pendant cinq secondes. Sans nouveau paquet, le récepteur peut attendre la prochaine commande avant de constater le saut de numéro. La pause du joueur prolonge alors, paradoxalement, le son erroné à distance.

Des paquets de garde peuvent transporter une liste MIDI vide. Ils n'ajoutent pas de gestes au musicien, mais continuent à fournir des observations de séquence et des informations de récupération. Une liste vide de commandes n'est pas un journal vide, et ne signifie pas que le paquet entier est inutile.

Les rythmes de garde proposés dans le guide sont des exemples de conception, pas une horloge obligatoire pour toutes les installations. Le paramètre guardtime décrit dans la spécification de 2011 borne l'écart entre deux paquets successifs en unités de l'horloge RTP. Les valeurs présentées comme usuelles n'en constituent pas des limites normatives.

Surtout, la maîtrise de la congestion prime sur une fréquence de garde demandée. Le RFC 3551 expose la responsabilité de coexistence avec les autres flux sur un réseau partagé. Une application musicale ne gagne pas un droit illimité à la capacité parce qu'un défaut serait plus agréable s'il cessait vite. Le remède doit rester compatible avec le transport qui le porte.

Un nouvel auditeur peut manquer un ancien réglage

La politique fermée, utilisée par défaut, réduit le volume de l'historique grâce aux retours des récepteurs. Les rapports RTCP indiquent notamment le plus haut numéro de séquence reçu ; un autre mécanisme convenu peut remplir le rôle de retour. L'émetteur peut ainsi avancer son point de contrôle et alléger les journaux.

Mais un réglage ancien peut disparaître du journal alors qu'il manque à un nouvel arrivant. Un volume de canal fixé tôt dans la séance est connu des participants présents depuis le début. Celui qui rejoint plus tard peut recevoir tous les paquets récents sans jamais avoir appris ce volume. La circulation présente ne garantit pas une initialisation correcte.

La spécification demande à l'émetteur, lorsqu'il découvre un nouveau récepteur, de lui éviter un démarrage avec des défauts indéfinis. Il peut notamment protéger l'état courant des contrôleurs jusqu'à confirmation de réception. Dans certaines configurations de diffusion, un récepteur encore inconnu de l'émetteur ne dispose que de précautions incomplètes : il peut éviter des notes bloquées, pas deviner une valeur de volume absente.

Le RFC 8088, guide de conception de formats RTP publié en mai 2017, retient précisément l'intérêt de cet état résumé et de son élagage par retour RTCP. Il situe leur utilité dans les médias symboliques fortement dépendants d'un état. C'est une appréciation de conception, non une mesure de diffusion commerciale.

Ce que les textes permettent d'affirmer

La révision de 2011 corrige notamment des figures, de la syntaxe et des exemples de paramètres. Les auteurs y limitent leurs observations sur l'interopérabilité aux erreurs corrigées. Leur absence de problème connu n'est pas un certificat portant sur toutes les implémentations. De même, un constat de maturité formulé en 2011 ne doit pas devenir une statistique d'usage actuelle.

L'enregistrement audio/rtp-midi auprès de l'IANA fournit un nom commun et les références nécessaires pour interpréter le format. Il vise le transport en temps réel de flux MIDI. Il ne garantit ni la qualité d'un concert ni la restitution intégrale d'une interprétation.

La leçon historique est plus précise qu'une préférence générale pour la fiabilité. Certains événements ne peuvent plus être bien exécutés une fois leur moment passé. D'autres doivent malgré tout être corrigés, parce qu'ils continuent à agir. Le journal rend cette distinction exploitable par des machines sans abolir la perte qui l'a rendue nécessaire.