Summary

  • Der W3C-Arbeitsentwurf vom 15. Dezember 2011 beschrieb die Web Audio API als Routing-Graph aus AudioNode-Objekten in einem AudioContext: Webanwendungen konnten Klang bearbeiten und erzeugen.
  • Die W3C-Empfehlung vom 17. Juni 2021 legte zeitgesteuerte Parameter, Offline-Berechnung und eigene Verarbeitung mit AudioWorklet fest. Das Skript plant den Graphen; die Audiomaschinerie des Browsers führt ihn aus.

Im Proberaum steht eine alte Jukebox mit einem auffällig roten Knopf. Der Komponist verlangt einen Ton, der leise anfängt, nach links wandert, durch einen Filter geht und beim Aufprall einer Spielfigur endet. Die Jukebox schlägt vor, die Platte noch einmal von vorn zu spielen. Das ist kein Defekt. Es ist eine andere Stellenbeschreibung. Webseiten konnten Tondateien abspielen, doch für Klang, der auf jede Handlung reagiert, reichte ein Startsignal nicht.

Der W3C-Arbeitsentwurf vom 15. Dezember 2011 stellte eine Schnittstelle zum Bearbeiten und Erzeugen von Klang vor. Ihr Grundmodell war ein Audio-Routing-Graph: Verbundene AudioNode-Objekte bestimmen, welchen Weg das Signal nimmt. Eine Quelle kann in einen Filter, dann durch Pegelregelung und räumliche Anordnung bis zur Ausgabe laufen. JavaScript stellt die Verbindungen her. Die eigentliche Verarbeitung sollte laut Entwurf überwiegend in der optimierten zugrunde liegenden Implementierung stattfinden; direkte Skriptverarbeitung war ebenfalls möglich. Der Komponist steckt die Kabel, der Browser bringt die Luft zum Schwingen.

Die Aufgabenteilung hatte einen konkreten Anlass. Das HTML-Audioelement machte einfache Wiedergabe möglich und war bereits ein Fortschritt. Der Entwurf von 2011 zielte auf Spiele und interaktive Anwendungen, die mischen, filtern und synthetisieren mussten. Eine fertige Aufnahme kann eine Szene begleiten. Sie reagiert nicht von selbst auf die Position einer Spielfigur oder formt während des Spielens eine neue Klangfarbe. Der Graph lieferte gemeinsame Bauteile, aus denen jede Anwendung andere Schaltungen bauen konnte.

Die Bauteile waren keineswegs Zauberbegriffe. AudioContext beherbergte den Graphen. Quellknoten lieferten Material, ein Gain-Knoten regelte den Pegel, Filter veränderten Frequenzen, Delay brachte Zeitversatz, Analyse-Knoten lieferten Daten für Visualisierungen und ein Destination-Knoten führte zur hörbaren Ausgabe. Der frühe Entwurf kannte auch das Trennen und Zusammenführen von Kanälen. Mehrere Quellen konnten gemischt werden, eine Quelle konnte mehrere Effekte durchlaufen. Das hörbare Ergebnis hing an der Verdrahtung.

Hinzu kam ein musikalischer Takt. Ein Aufprall, der merklich später als das Bild zu hören ist, wirkt nicht raffiniert, sondern kaputt. Die frühe API beschrieb die Zeit eines AudioContext und die Planung von Klangereignissen relativ dazu. Eine Anwendung konnte festlegen, wann ein Ton beginnen und enden sollte. Sie musste nicht für jede einzelne Klangprobe auf einen JavaScript-Timer hoffen, während die Seite nebenbei Menüs und Animationen abarbeitet.

Der Arbeitsentwurf vom 10. Oktober 2013 hielt am Graphen als Hauptmodell fest. Er war bereits der fünfte öffentliche Entwurf. Seine Anwendungsfälle umfassten komplexe Spiele, interaktive Anwendungen, Mischen und Filterung. Für ein ganzes Lied blieb der Play-Knopf gut. Wer den Klang einer Szene aus veränderlichen Teilen bauen wollte, brauchte das neue Pult.

Mit der W3C-Empfehlung vom 17. Juni 2021 wurde die Partitur deutlich ausführlicher. AudioParam erlaubte es, Werte wie den Pegel entlang der Audiozeit zu verändern, statt eine hektische Folge von Seitenaufrufen zu verwenden. OfflineAudioContext konnte den Graphen in einen Puffer berechnen, ohne ihn sofort über Lautsprecher auszugeben. Eine Anwendung konnte so ein Ergebnis vorbereiten, untersuchen oder später wiederverwenden. Quelle, Verarbeitung, Zeit und Ziel blieben die Grundordnung des Systems.

Für eigene Effekte gab es AudioWorklet. Die Empfehlung beschrieb ein AudioWorkletNode im Graphen und einen zugehörigen AudioWorkletProcessor in einer besonderen Verarbeitungsumgebung. Der Entwickler konnte einen eigenen Baustein hinzufügen, während der Browser einen passenden Ausführungspfad für den Klang bereitstellte. Die Spezifikation unterschied Kontroll- und Rendering-Thread. Ein Menü darf beim Öffnen kurz warten. Ein Ton, der exakt zur Handlung gehört, kann sich solche Höflichkeit nicht leisten.

Die W3C-Veröffentlichungsgeschichte reicht vom Entwurf im Dezember 2011 bis zur Empfehlung im Juni 2021. Das sind Daten von Normtexten, keine Messung der Nutzung und kein Wettlauf einzelner Browser. Die lange Strecke zeigt, wie viele Regeln ein verlässlicher Klanggraph braucht: Verbindungen, Kanäle, Uhren, Verarbeitungsformen und Ausgabe. Viele Knöpfe allein ergeben noch kein gutes Mischpult. Entscheidend ist, dass die angeschlossenen Teile berechenbar zusammenarbeiten.

Den Anwendungen blieb viel Raum. Ein Spiel konnte eine Explosion im Raum platzieren. Ein Online-Instrument konnte Oszillatoren und Filter verbinden. Ein Unterrichtswerkzeug konnte mit einem Analyser den Klang sichtbar machen. Der Browser stellte die gemeinsame Maschinerie; jedes Programm entwarf seine eigene Schaltung. Aus „spiele diese Datei“ wurde „erzeuge diesen Klang auf diesem Weg“.

Die Jukebox darf bleiben. Wer nur ein Lied hören will, ist mit einem einzigen Knopf bestens bedient. Für ein Orchester, das jeder Bewegung folgt, wäre er allerdings dramatisch unterbesetzt. Web Audio brachte das Mischpult in den Browser und gab der Anwendung Zugriff auf die Regler. Ob die Komposition gelungen ist, bleibt Sache der Komponisten.