ctOpus, Schritt für Schritt

opusenc liest die WAV-Datei, rechnet sie von 44,1 auf 48 kHz um, kodiert sie und schreibt Ogg-Seiten – alles auf einem Thread, nacheinander. Während er liest oder schreibt, wartet der Thread auf die Datei. Jede Stufe trägt Zustand von Frame zu Frame: die Filterspeicher, die Energievorhersage, das Bit-Reservoir und den Bitstrom. Ein Kern arbeitet, die anderen warten.

Diese Bits sind die Messlatte: Jedes weitere Bild muss Byte für Byte dieselbe .opus-Datei schreiben. ctOpus beginnt mit einer Portierung des Encoders, Funktion für Funktion: Auf einem Thread ist sie gleich schnell wie opusenc (2,09 s) und bit-identisch.

Die Datei-Ein- und -Ausgabe wird vom Kodieren getrennt. Lesen und Schreiben werden Tasks auf dem I/O-Scheduler; ein einziger Task kodiert und macht alles, was opusenc macht. Lesen liest mit fünf überlappenden Anfragen zu 1 MB in einen Lesepuffer voraus, der Encode-Task nimmt sich nur noch fertige Blöcke. Die Ogg-Seiten kopiert der Encode-Task in einen Schreibpuffer, und Schreiben bringt volle Blöcke in die Datei, zwei Anfragen gleichzeitig.

Warten Lesen oder Schreiben auf die Platte, belegen sie keinen Thread: Der I/O-Scheduler führt in der Zeit den anderen Task aus. Gemessen mit der Datei frisch von der Platte ist das gleich schnell oder schneller – und bit-identisch in jeder Prüfung. Mit einem einzigen Encode-Task dauern beide Wege gleich lang; mit dem ganzen Graphen von Bild 10 spart derselbe Schritt 2 bis 3 %, weil dort der Encode-Task die Ogg-Seiten auf dem kritischen Pfad schrieb: 16 Threads 0,486 → 0,474 s, 4 Threads 0,780 → 0,760 s.

Verteilen (Distribute) entpackt die WAV-Daten in die Samples – auf dem Rechen-Scheduler mit hoher Priorität (dicker Rahmen), weil alle Resampler auf seine Blöcke warten. Der Resampler berechnet jedes Ausgabesample allein aus der Eingabe, seine Filterphase folgt aus der Position – Blöcke lassen sich deshalb unabhängig rechnen, auf allen Kernen, in beliebiger Reihenfolge, mit exakt denselben Werten. Der Encode-Task nimmt die Blöcke in Reihenfolge aus dem Blockring.

Der Resampler ist aus dem kritischen Pfad verschwunden: 1,86 s bei Komplexität 10, bei Komplexität 0 0,70 s statt 0,97 s (1,38×). Übrig bleibt fast nur noch der serielle Encoder.

Die Tonalitäts-Analyse eines Frames hängt nur vom Signal ab, nicht von den Entscheidungen des Encoders. Sie wird ein eigener Task, der dem Encode-Task vorausläuft und sein Ergebnis für jeden Frame in einen Ring legt. Der Blockring hat jetzt zwei Leser: Ein Platz ist erst wieder frei, wenn beide ihn haben. Der Encode-Task liest die Blöcke weiterhin selbst (der Pfeil rechts).

Dazwischen wurde der Encoder selbst nach C++ portiert: Das allein senkte die Laufzeit von 1,86 auf 1,73 s.

Zeitstempel zeigen: Der Encode-Task wartet jetzt weder auf Blöcke (1 ms) noch auf die Analyse (2 ms). Die verbleibenden 1,5 s sind reine serielle Arbeit, davon etwa 0,67 s die Quantisierung der Frequenzbänder.

Auch ein Teil des Encoders hängt nur vom Signal ab, nicht von früheren Entscheidungen: Vorverzerrung, Ton- und Transientenerkennung, die Tonhöhensuche. Der Analyse-Task rechnet diese Signalstufe voraus und gibt Signal-Frames mit seinen Ergebnissen weiter.

Der Encode-Task vergleicht die komplette Eingabe dieser Stufe – etwa 16 KB je Frame – und übernimmt einen Frame nur bei exakter Gleichheit. Läuft die Analyse einmal auseinander, wird es langsamer, nie falsch. Gemessen: 12.725 von 12.725 Frames übernommen. ctOpus braucht jetzt 0,62 der Zeit von opusenc im selben Lauf, vorher 0,74.

Nach der Signalstufe rechnet die Analyse jetzt auch das Front-End des nächsten Frames: den Vorfilter, die Transformation in den Frequenzbereich, die Bandenergien und, ab 5 ms langen Frames, Normierung, Bit-Verteilung und Zeit-Frequenz-Entscheidungen. Sie hängen nur von wenigen Werten des seriellen Encoders ab, und die Analyse nimmt sie einfach an – „wie beim letzten Abgleich“.

Der Encode-Task übernimmt ein Front-End nur, wenn diese Werte stimmen. Nach einem Fehlschuss schickt er seine echten Werte zurück (gestrichelt), und die Analyse rechnet ab dort neu. Trefferquote: 12.724 von 12.725 Frames. Komplexität 10 ist jetzt etwa so schnell wie opusenc mit Komplexität 0 (0,97 s im selben Lauf).

Das Front-End wird ein eigener Task: Die Analyse muss für eine Korrektur nicht mehr unterbrochen werden, und der Encode-Task wartet nicht mehr auf sie.

Bei hoher Komplexität quantisiert der Encoder jedes Stereo-Band zweimal, vom selben Zustand aus, mit ab- und mit aufgerundetem Stereowinkel, und behält den günstigeren Versuch. Den zweiten Versuch rechnet jetzt ein Helfer, gleichzeitig mit dem ersten im Encode-Task. Ein Versuch dauert nur 1 bis 2 µs, deshalb warten beide Seiten zuerst aktiv und schlafen erst danach.

Ziel erreicht: Komplexität 10 ist 19 % schneller als opusenc mit Komplexität 0 und 2,7-mal so schnell wie opusenc mit Komplexität 10.

Der Graph bleibt gleich, die Arbeit wandert. Die Eingangsstufe – Gleichanteil-Filter, Stille-Erkennung, Frame-Energie, Stereobreite – geht in die Analyse, die Stereowinkel der obersten Ebene gehen in das Front-End. Nach dem letzten Rundungsversuch lässt der Encode-Task Arbeit weg, die nur den Versuchen diente, und er kopiert weniger.

Was der Encode-Task nicht selbst rechnen muss, verkürzt die serielle Kette, und jede Übernahme ist an einen exakten Vergleich gebunden. Im selben Lauf braucht opusenc 1,02 s bei Komplexität 0 und 2,11 s bei Komplexität 10.

Innerhalb eines Frames sind die Bänder seriell, zwischen zwei Frames gehen aber nur zwei kleine Dinge über: ein paar übrige Bits am Ende des Frames und der Zustand des Bitstrom-Kodierers, der erst spät gebraucht wird, wenn überhaupt. Der Encode-Task kopiert deshalb seinen Zustand, bevor er Frame N quantisiert, setzt für die übrigen Bits einen Schätzwert ein, und die Spekulation quantisiert gleichzeitig Frame N+1 auf der Kopie und protokolliert dabei jedes geschriebene Symbol.

Kommt der Encode-Task bei Frame N+1 an, prüft er jede Annahme. Stimmen alle, spielt er nur das Protokoll ab, statt den Frame zu rechnen; sonst bricht die Spekulation an der nächsten Bandgrenze ab. Etwa 96 % der spekulierten Frames werden übernommen – rund 20 % schneller. Für ihren Rundungsversuch hat die Spekulation einen eigenen Helfer.

Mit genug Threads arbeitet der serielle Encoder mehrere Frames voraus: Die Kopie der ersten Spekulation baut die Kopie für die zweite, diese die für die dritte. Bis zu drei Spekulationen rechnen die Frames N+1 bis N+3, während der Encode-Task Frame N quantisiert, ab 12 Threads jede mit einem eigenen Helfer. Das ist der heutige Graph.

Für die Testdatei braucht ctOpus bei Komplexität 10 0,50 s, bei Komplexität 0 0,31 s – opusenc 2,21 s und 0,99 s. ctOpus mit maximaler Komplexität ist doppelt so schnell wie opusenc mit minimaler. Für 45 Stunden Musik braucht es 289,5 Sekunden statt 21 Minuten, 561-fache Echtzeit – alle 343 Dateien bit-identisch.

Bis hierher war der Graph über den Code verteilt: Alle Tasks griffen in eine gemeinsame Datenstruktur. Jetzt steht der Graph an einer Stelle im Code, so wie er gezeichnet ist: Er besitzt jede Kante und jeden Knoten in der Reihenfolge des Datenflusses, startet die Tasks mit ihren Prioritäten und wartet, bis alle fertig sind. An keiner Rechnung ändert sich etwas.

Der Weg mit einem einzigen Encode-Task bleibt als Referenz – etwa für Eingaben mit 48 kHz, die nichts zu resampeln haben. Mit dem asynchronen Lesen und Schreiben ist er genau der Graph von Bild 2.