Zusammenfassung

  • Das Journal beschreibt eine begrenzte, für Korrekturen geeignete Vergangenheit. Es überträgt nicht jedes verlorene Paket erneut und bewahrt nicht sämtliche früheren Anschläge auf.
  • MIDI-Befehle verändern einen Zustand. Ein fehlender Anschlag kann vorübergehen; ein fehlender Abschalt- oder Lautstärkebefehl kann die weitere Wiedergabe dauerhaft verfälschen.
  • Empfänger treffen lokale Wiederherstellungsentscheidungen innerhalb gemeinsamer Regeln. Verlauf, Initialisierung, Stille und Netzbelastung bestimmen, was diese Entscheidungen tatsächlich leisten können.

Eine Vergangenheit mit ausdrücklich gesetzter Grenze

Ein RTP-MIDI-Paket enthält neue Befehle und kann zugleich Auskunft über ältere geben. Doch selbst ein Wiederherstellungsjournal ist keine vollständige Aufzeichnung. Beginnt sein Prüfpunkt bei C und trägt das aktuelle Paket die Nummer I, dann umfasst die relevante Vorgeschichte die Pakete C bis I−1. Die neuen Befehle aus I gehören noch nicht zu diesem Verlauf.

Diese Unterscheidung aus RFC 6295, veröffentlicht im Juni 2011, wirkt zunächst wie eine Frage des Formats. Tatsächlich beschreibt sie den Umfang des Versprechens. Ein Empfänger bekommt einen Ausschnitt, aus dem er bestimmte Folgen eines Verlusts beheben kann. Er bekommt nicht automatisch alles, was irgendwann zuvor gespielt wurde.

Auch die Fähigkeit, beliebig viele verlorene Pakete zu behandeln, hat deshalb eine Grenze: Diese Pakete müssen innerhalb des abgedeckten Verlaufs liegen. Eine beliebig lange Unterbrechung wird dadurch nicht folgenlos. Der Prüfpunkt hilft dem Empfänger festzustellen, ob das Journal weit genug zurückreicht.

Der Unterschied zwischen einem brauchbaren Reparaturzustand und einem lückenlosen Archiv ist der Schlüssel zu diesem Entwurf. Das System wollte eine Aufführung wieder auf einen tragfähigen Stand bringen, nicht die verstrichene Zeit zurückdrehen.

Wenn ein einzelner Befehl die Zukunft verändert

MIDI transportiert symbolische Anweisungen für Instrumente. Ein Empfänger erzeugt den Klang aus diesen Anweisungen und seinem bereits bestehenden Zustand. Es werden hier keine fehlenden Stücke einer fertigen Tonaufnahme rekonstruiert.

Deshalb kann ein sehr kurzer verlorener Befehl lange Folgen haben. RFC 4695 unterschied im November 2006 zwischen vorübergehenden und unbestimmt anhaltenden Störungen. Ein verlorenes NoteOn lässt möglicherweise einen Ton ausfallen. Dessen Abwesenheit endet normalerweise mit der vorgesehenen Dauer dieses Tons. Fehlt hingegen NoteOff, kann ein Ton weiterklingen. Ein verlorener Befehl für die Kanallautstärke kann alle folgenden Töne zu laut oder zu leise werden lassen.

Das genaue Ergebnis hängt vom Instrument, seiner Hüllkurve, Pedalen und späteren Befehlen ab. Nicht jedes verlorene NoteOff führt zwangsläufig zu einem endlosen Klang. Aber ein Protokoll darf nicht darauf bauen, dass irgendein späteres Ereignis die fehlende Anweisung zufällig ersetzt.

Zwei identische Verlustzähler können somit sehr unterschiedliche Aufführungen beschreiben. Der eine steht für eine kurze Lücke, der andere für einen Fehler, der sich in jede folgende Phrase fortsetzt. Wiederherstellung muss diese Wirkung auf den Zustand kennen.

RTP kennt die Reihenfolge, nicht den richtigen Klang

RFC 3550 stellt seit Juli 2003 den grundlegenden RTP-Rahmen mit Sequenznummern, Zeitstempeln und Empfangsbeobachtung bereit. Das Dokument verspricht ausdrücklich weder sichere noch rechtzeitige noch geordnete Zustellung. Die Angaben schaffen Werkzeuge zum Umgang mit einer unvollkommenen Übertragung.

Eine Lücke in der Nummernfolge verrät allerdings nicht, ob ein Instrument gerade auf einer falschen Lautstärke stehen geblieben ist. Diese Bedeutung liegt bei der Anwendung. Das MIDI-Format ergänzt deshalb einen Verlauf, den der Empfänger mit seinem eigenen Wissen vergleichen kann.

Im journalgestützten Strom liefert das Paket, das eine Verlustphase beendet, Informationen für diesen Vergleich. Der Empfänger führt bei Bedarf lokale Korrekturbefehle aus. Ein von ihm erzeugtes NoteOff kann etwa eine Wirkung beenden, deren ursprünglicher Abschaltbefehl nie angekommen ist.

Das Verfahren beruht nicht auf der erneuten Übertragung jedes fehlenden Pakets. Sein Auftrag lautet, unbestimmt anhaltende Störungen der Wiedergabe zu verhindern. Eine Störung, die bereits hörbar geworden ist, lässt sich nicht ungeschehen machen. Sie kann aber von einem offenen Ende auf einen begrenzten Zeitraum zurückgeführt werden.

Der wiedergefundene Anschlag muss nicht erklingen

Die Gegenrichtung ist ebenso wichtig. Wird ein ausgefallenes NoteOn erst später bekannt, kann sein nachträgliches Auslösen die Musik zusätzlich stören. Die sachliche Richtigkeit einer historischen Information macht ihre sofortige Ausführung noch nicht sinnvoll.

Kapitel N des Journals behandelt die üblichen wechselnden NoteOn- und NoteOff-Muster einer Tonhöhe. Sein NoteOn-Eintrag enthält nicht den genauen ursprünglichen Ausführungszeitpunkt. Ein Y-Bit empfiehlt, den Ton zu spielen oder zu überspringen. Es ist keine Verpflichtung, jeden in der Vergangenheit erkannten Anschlag nachzuholen.

Der im November 2006 erschienene Implementierungsleitfaden RFC 4696 beschreibt, wie ein Empfänger einen verspäteten Anschlag auslassen und dennoch seine Wiederherstellungsdaten entsprechend fortschreiben kann. So bleibt die Behandlung späterer Befehle konsistent, ohne einen Ton außerhalb seines musikalischen Zusammenhangs hinzuzufügen.

Die dargestellten Algorithmen erfassen nicht jede mögliche Spielweise. Überlappende Anschläge derselben Tonhöhe benötigen zusätzliche Unterstützung durch Kapitel E. Ein vereinfachtes Muster für Tastaturen oder Schlagflächen ist kein vollständiges Modell aller Gitarren- und Blasinstrument-Controller.

Auch das Loslassen ist nicht immer akustisch eindeutig. Ein Haltepedal kann einen Ton trotz NoteOff erhalten. Die relative Reihenfolge von Pedaländerung und Abschaltbefehl lässt sich aus dem Journal nicht in jedem Fall vollständig rekonstruieren. Wo die eigene Vorgeschichte des Empfängers nicht weiterhilft, bevorzugt die Spezifikation die Vermeidung fälschlich gehaltener Töne, gegebenenfalls um den Preis einer kurzen hörbaren Unsauberkeit.

Stille kann die Fehlererkennung verzögern

Der Leitfaden verdeutlicht das Problem an einer Pause. Ein NoteOff-Paket geht verloren; danach erzeugt der Musiker fünf Sekunden lang keinen weiteren Befehl. Ohne ein neues RTP-Paket kann der Empfänger bis zum nächsten Anschlag warten müssen, um den Sprung in der Folge zu sehen. Die Stille am sendenden Instrument kann am empfangenden Instrument gerade keinen stillen Zustand erzeugen.

Es handelt sich um ein Entwurfsbeispiel, nicht um eine dokumentierte Konzertpanne. Als Gegenmaßnahme diskutiert der Text Schutzpakete mit einer leeren MIDI-Befehlsliste. Sie erfinden keine musikalische Aktion, führen aber die Paketfolge fort und können Wiederherstellungsinformationen liefern.

Dabei sind eine leere Befehlsliste, ein leeres Journal und ein Strom ohne Journal nicht gleichzusetzen. Wer das Paket nur nach neuen Noten bewertet, übersieht seine Aufgabe für den noch offenen Zustand.

Die im Leitfaden vorgeschlagenen Abstände sind Beispiele, keine für alle Installationen verbindlichen Taktwerte. Der Parameter guardtime aus der späteren Spezifikation begrenzt den Abstand aufeinanderfolgender Pakete in Einheiten der RTP-Zeitbasis. Auch dort ist der als typisch beschriebene Wertebereich ausdrücklich keine normative Grenze.

Zudem geht die Überlastkontrolle einem angeforderten Schutzpaketrhythmus vor. RFC 3551 erläutert die Verantwortung für ein angemessenes Nebeneinander mit anderen Strömen. Ein musikalisch störender Fehler begründet keinen unbegrenzten Anspruch auf gemeinsame Netzkapazität. Mehr Reparaturgelegenheiten helfen wenig, wenn sie neue Verluste verursachen.

Rückmeldungen verkürzen den Verlauf, nicht die Verantwortung

Die voreingestellte geschlossene Rückkopplung nutzt Empfangsberichte, um den Prüfpunkt voranzuschieben und den Journalumfang zu verringern. Üblicherweise dient dazu die höchste erweiterte empfangene Sequenznummer in RTCP-Berichten; eine andere vereinbarte Rückmeldung kann dieselbe Funktion übernehmen.

Ein solcher Bericht ist kein Beleg für eine fehlerlos gehörte Aufführung. Er erlaubt eine Entscheidung über den weiter benötigten Verlauf, weil der Empfänger seinerseits die vorgeschriebenen Reparaturen leisten muss. Die Einsparung beim Sender setzt Arbeit am anderen Ende voraus.

Neu hinzukommende Empfänger zeigen die Grenze dieser Einsparung. Ein lange zuvor gesendeter Lautstärkewert kann aus dem kurzen Verlauf verschwunden sein. Bisherige Teilnehmer kennen ihn, ein neuer nicht. Sobald der Sender von diesem Teilnehmer weiß, muss er einen Beginn ohne entsprechende Dauerfehler sicherstellen, etwa durch erneute Absicherung des aktuellen Controllerzustands.

Ein noch unbekannter Empfänger in einer Mehrpunktumgebung kann nur begrenzt vorsorgen. Er kann vorsichtig mit möglicherweise hängenden Tönen umgehen, aber keinen nie empfangenen Lautstärkewert erraten. Dass aktuelle Pakete eintreffen, beweist weder einen vollständigen Anfangszustand noch eine passende Historienabdeckung.

Ein Leitfaden ist kein einzig zulässiger Empfänger

Die im Leitfaden beschriebene NMP-Implementierung verwirft ungeordnet eintreffende alte Pakete. Eine Journalreparatur könnte bereits Befehle ausgeführt haben, die das alte Paket nun verdoppeln würde. Vollständigkeit auf der Transportebene kann damit den gegenwärtigen Anwendungszustand beschädigen.

Doch RFC 4696 ist ausdrücklich informativ und nicht normativ. Der Beispielentwurf setzt besondere Netzeigenschaften voraus, schützt nur einen Teil der Befehle und verzichtet auf einen Wiedergabepuffer. Der Text räumt ein, dass er damit eine genannte Interoperabilitätsvorgabe zur Pufferfähigkeit nicht vollständig erfüllt.

Die normative Pflicht ist enger: Der Umgang mit ungeordneten Paketen darf keine unbestimmt anhaltenden Fehler erzeugen. Ein gepufferter Empfänger kann mit der Wiederherstellung bis zum Abspielzeitpunkt warten, weil ein vermeintlich verlorenes Paket möglicherweise noch rechtzeitig eintrifft. Gemeinsame Semantik und örtliche Algorithmuswahl sind zwei verschiedene Ebenen.

Das gilt auch für Sitzungsgrenzen. Das erste Paket wird wie das Ende eines Verlustereignisses behandelt; beim Verlassen darf die Wiedergabe nicht in einem unbegrenzt fehlerhaften Zustand zurückbleiben. Die Verantwortung endet nicht am Netzwerkanschluss.

Was die spätere Geschichte belegt

Im Mai 2017 hob der informative Entwurfsleitfaden RFC 8088 die Zusammenfassung von Zustand und dessen Kürzung mithilfe von RTCP als interessante Eigenschaften von RTP MIDI hervor. Er verortete ihren Nutzen bei stark zustandsabhängigen symbolischen Medien. Das ist eine technische Einordnung, keine Marktstatistik.

Der IANA-Eintrag für audio/rtp-midi schafft einen gemeinsamen Namen sowie Verweise auf Parameter und Spezifikationen. Er beschreibt Echtzeitübertragung von MIDI-Strömen. Eine Registrierung kann Verständigung erleichtern, aber keine konkrete Aufführung auf ihre Qualität prüfen.

Auch die Überarbeitung von 2011 ist begrenzt zu lesen. Sie beseitigt unter anderem Fehler in Abbildungen, Syntax und Konfigurationsbeispielen. Die Aussagen der Autoren über nicht bekannte Interoperabilitätsprobleme betreffen diese Korrekturen. Weder daraus noch aus damaligen Einschätzungen zur Verbreitung folgt ein heutiges Urteil über sämtliche Implementierungen.

Das Journal bewahrt letztlich gerade so viel Vergangenheit, wie die gewählte Schutzregel benötigt. Es macht den Verlust nicht unsichtbar. Es verhindert, dass ein verlorener Befehl unbegrenzt weiterwirkt. Darin liegt eine anspruchsvolle Form von Zuverlässigkeit, die ihre Grenzen offenlegt, statt eine Aufführung nachträglich für ungeschehen zu erklären.