AOO: Low-Latency Peer-to-Peer Audio-Streaming und Messaging

AOO (Audio over OSC) ist eine Software-Bibliothek für Peer-to-Peer-Audio-Streaming- und Messaging. AOO-Netzwerke bestehen aus mehreren Endpunkten, sogenannten Sources und Sinks, die ad-hoc untereinander verbunden und wieder getrennt werden können. Ein spezieller Verbindungsserver ermöglicht es den Peers, sich gegenseitig über ihren Namen zu adressieren und ermöglicht die Kommunikation über das öffentliche Internet.

Die Referenzimplementierung des AOO-Protokolls ist in C++ geschrieben. Die Bibliothek bietet eine einfache C- und C++-API und kann leicht in Host-Anwendungen oder Audio-Plugins eingebettet werden. AOO ist recht effizient bezüglich CPU- und Speichernutzung und eignet sich daher für eingebettete Geräte, wie z. B. den ESP32. Momentan umfasst AOO die folgenden Komponenten:

• C++ Bibliothek (mit C API)
• Pure-Data-External
• aooserver Kommandozeilenprogramm

Diese befinden sich noch in Entwicklung:

• SuperCollider-Extension
• aoosend und aooreceive Kommandozeilenprogramme

Die folgenden Komponenten sind wünschenswert, aber entweder für die Zukunft geplant oder für Drittentwickler vorgesehen:

• Max/MSP-External
• Audio-Plugins (VST3, AU, etc.)
• Anbindungen an andere Programmiersprachen (Rust, Java, Python, etc.)

AOO ist Open-Source und wird unter der BSD-Lizenz veröffentlicht. Das offizielle Repository befindet sich unter AOO (audio over OSC). Das README enthält Build- und Installationsanweisungen. Release-Notes und vorgefertigte Binärdateien findest du unter hier. Für Fehlerberichte oder Funktionswünsche verwende bitte den Issue-Tracker.

Geschichte

Die Vision von AOO wurde erstmals 2009 von Winfried Ritsch zusammen mit einer Proof-of-Concept-Implementierung für eingebettete Geräte vorgestellt. In seinem Paper towards message based audio systems (Ritsch 2014) stellt er die folgenden Anforderungen:

• Austausch von Audiosignalen zwischen verteilten Audiosystemen
• beliebige Ad-hoc-Verbindungen
• verschiedene Audioformate und Samplingraten
• Synchronisierung und geringstmögliche Latenzzeit
• Audiodaten nur bei Bedarf

Im Jahr 2010 wurde AOO von Wolfgang Jäger als Bibliothek mit Externals für Pure Data implementiert, der praktische Einsatz blieb jedoch beschränkt. Im Jahr 2020 begann Christof Ressi mit einer vollständigen Überarbeitung (AOO 2.0), die erheblich vom ursprünglichen Design abweicht. Zum Zeitpunkt der Erstellung dieses Artikels (2024) befindet sich AOO 2.0 noch im Beat-Stadium, aber eine erste stabile Version ist für dasselbe Jahr geplant.

Anwendung

AOO 2.0 wurde ursprünglich im Februar 2020 für das Kunstprojekt Reenactment of Sonic Projections von Bill Fontana entwickelt. Die Idee war, Audio-Livestreams von mehreren bestimmten Orten in Graz ins Kunsthaus zu übertragen. Winfried Ritsch war für die technische Umsetzung verantwortlich und entwickelte zu diesem Zweck die DIY Audio Stream Box. Die Übertragung der Streams erfolgte mit dem AOO-Protokoll über ein unabhängiges Funknetz, das von Amateurfunkern betrieben wird.

© Winfried Ritsch

Stream boxes für Reenactment of Sonic Projections. 

AOO wurde kurz darauffür das Virtual Rehearsal Room (VRR) Projekt verwendet, welches Studierenden des PPCM-Programms an der Kunstuniversität Graz ermöglichte, während der frühen Covid-Pandemie aus der Ferne weiter zu proben. Zu dieser Zeit gab es keine Softwarelösungen, die unseren Anforderungen entsprachen (einfache Einrichtung, plattformübergreifend, hohe Audioqualität, Stereopanning, Hall usw.), also haben wir in kurzer Zeit einen Prototyp in Pure Data mithilfe der AOO-Bibliothek erstellt. Die Studierenden spielten in ihren privaten Wohnungen in ganz Europa, oft unter nicht gerade idealen Bedingungen: geräuschhafte Umgebung, billige Audioausrüstung, schlechte Internetverbindung, etc. Am Ende des Semesters veranstalteten wir zwei Online-Konzerte/, für die der VRR zu einer Virtual Concert Hall (VCH) erweitert wurde – mit überzeugenden Ergebnissen!

Seitdem wurde AOO in mehreren Kunstprojekten eingesetzt. Bemerkenswerte Beispiele sind die Performances TRACK und BAD BLOCK der französischen Theatergruppe La Boîte à sel. In TRACK erzeugt ein Performer/Komiker/Beatboxer Live-Samples, die auf kleinen Lautsprechern in Spielzeugeisenbahnwaggons abgespielt werden. Diese Waggons bewegen sich auf einer ausgedehnten Gleisanlage und transportieren die Klänge somit durch den ganzen Raum. AOO wird für das Streaming der Klänge vom Computer zu den einzelnen Waggons verwendet. BAD BLOCK verwendet insgesamt 104 tragbare, kabellose Streaming-Boxen, die es dem Performer und dem Publikum ermöglichen, mit den Klangquellen körperlich zu interagieren.

© Sonobus Screenshot

Screenshot der SonoBus App (https://sonobus.net/)

AOO wird auch im IEM Computer Music Ensemble, im TPF-Forschungsprojekt oder etwa in der Online-Jamming-App SonoBus verwendet. Außerdem sind mir mindestens zwei Unternehmen bekannt, welche die AOO-Bibliothek in ihren Produkten einsetzen.

Grundsätzlich ermöglicht AOO auch die Herstellung drahtloser Lautsprecher oder Mikrofone. Dies kann z. B. sehr nützlich für Mehrkanal-Sound-Installationen sein, bei denen es unpraktisch oder sogar unmöglich wäre, Audiokabel zu verlegen, insbesondere wenn es sich um mobile Geräte handelt. Wie bereits eingangs erwähnt, kann AOO auf eingebetteten Systemen wie dem ESP32 verwendet werden. Ein Proof-of-Concept mit dem Olimex ESP32-ADF Board hat gezeigt, dass es ohne Weiteres möglich ist, über WIFI von einem Computer zu 18 Lautsprechern zu streamen, und zwar mit einer Gesamtlatenz von weniger als 50 Millisekunden. Die endgültige Version von AOO wird mehrere Beispiele für die ESP32-Plattform enthalten.

Features

AOO unterstützt bis zu 256 Audiokanäle und setzt keine Beschränkungen bei der Blockgröße und der Samplingrate. Wenn Sources und Sinks mit unterschiedlichen Samplingraten und/oder Blockgrößen laufen, werden die Streams automatisch entsprechend neu geblockt bzw. gesampelt. Das Streaming-Format kann unabhängig von der Hardware-Puffergröße und der Samplingrate eingestellt werden. Dies ist entscheidend, denn die hostseitigen Audio-Einstellungen sind nicht immer für das Streamen geeignet. Wenn z. B. Pure Data mit einer Blockgröße von 64 Samples @ 96 kHz läuft, könnte man als Streaming-Format 256 Samples @ 48 kHz wählen, um die nötige Bandbreite zu reduzieren. AOO beherrscht auch dynamisches Resampling, um Taktfrequenzabweichungen zwischen verschiedenen Rechnern auszugleichen (siehe Adriaensen 2005).

© Christof Ressi

Automatisches Reblocking und Resampling zwischen Computern.

AOO unterstützt unterschiedliche Audiocodecs. Die integrierten Optionen sind derzeit PCM (mit verschiedenen Bittiefen) für beste Audioqualität sowie Opus  für eine optimierte Übertragung über das Internet oder Netzwerke mit geringer Bandbreite. Die Wahl fiel deshalb auf Opus, weil es selbst bei sehr niedrigen Bitraten eine gute Audioqualität bietet, nur eine geringe Verzögerung verursacht und Paketverluste kaschieren kann, was es ideal für Audio-Streaming-Anwendungen mit niedriger Latenz macht. PCM und Opus scheinen die meisten Anwendungsfälle abzudecken, es ist aber möglich, weitere Codecs über die Code-Plugin-API hinzuzufügen. Als dritte integrierte Option – und Kompromiss zwischen PCM und Opus – käme der QOA-Codec in Frage.

AOO-Sinks verwenden einen Jitterbuffer, um Netzwerk-Jitter und die Umordnung von Paketen auf Kosten einer zusätzlichen Verzögerung zu kompensieren. Die Buffer-Latenz kann dynamisch eingestellt werden. Im Falle eines Paketverlustes kann die Sink die Source auffordern, die fehlenden Daten erneut zu senden – vorausgesetzt, die Latenzzeit ist groß genug, um die erneut gesendeten Pakete rechtzeitig empfangen zu können. Für den Echtzeiteinsatz sollte man die Latenzzeit so gering wie möglich halten und sich stattdessen auf den vom Opus-Codec verwendeten Packet-Loss-Concealment-Algorithmus verlassen. Bei Über- oder Unterschreitung des Jitterbuffers gibt die Sink entsprechende Events aus, die von der Anwendung verarbeitet werden können. Es ist auch möglich, diagnostische Informationen über verlorene, umgeordnete oder erneut gesendete Pakete zu erhalten. Dies kann etwa dazu verwendet werden, die Bitrate im Opus-Codec anhand des Paketverlusts dynamisch anzupassen.

© Christof Ressi

Die Arbeitsweise des Jitterbuffers.

Jede AOO-Source kann an mehrere Sinks senden. Umgekehrt können die Sinks von mehreren Sources empfangen, Audiosignale auf demselben Kanal werden summiert. Folglich können Sources und Sinks jede mögliche Netzwerktopologie bilden.

© Christof Ressi

Beispiele möglicher Netzwerktopologien.

Streams können aus beiden Richtungen initiiert werden: Die Source kann entscheiden, an eine oder mehrere Sinks zu senden. Umgekehrt kann die Senke kann eine oder mehrere Sources "einladen", welche ihrerseits die Anfrage annehmen oder ablehnen können.

© Christof Ressi

Gegenseitig Initiierung von AOO-Streams.

Streams können jederzeit, samplegenau und ohne Latenz gestartet und gestoppt werden. Die Startnachricht kann zusätzliche Metadaten enthalten, z. B. um musikalische Eigenschaften anzugeben oder das Kanal-Layout zu beschreiben. Mögliche Datentypen sind: binär, MIDI, OSC, JSON, XML, FUDI oder Zahlen-Arrays.

In Kombination ermöglichen diese Merkmale verschiedene interessante Anwendungsfälle:

• AOO-Netzwerke sind dynamisch und können ihre Topologie im Laufe der Zeit frei ändern.
• Streams können (vorübergehend) gestoppt werden, wenn kein Signal vorhanden ist, um Bandbreite und Rechenleistung zu sparen.
• AOO ermöglicht einen "Event-basierten" Ansatz, bei dem eine Folge von Klangereignissen als eine Reihe von kurzen Streams übertragen werden kann.

AOO-Streams können auch eine beliebige Anzahl an Messages unterschiedlicher Datentypen beinhalten. Diese sogenannten stream messages können etwa verwendet werden, um Panning-Informationen einzubetten, MIDI-Nachrichten zu senden oder Parameter-Modulationsdaten zu übermitteln. Sie enthalten samplegenaue Zeitstempel, so dass die ursprüngliche Zeitdifferenz zwischen den Messages so genau wie möglich bewahrt werden kann, auch nach mehrmaligem Reblocking und Resampling.

© Christof Ressi

AOO stream messages mit Reblocking und Resampling.

AOO-Sources und -Sinks können zwar direkt über ihre IP-Adresse adressiert werden, doch ist es oft bequemer, sich gegenseitig mit Namen anzusprechen. Wenn sich AOO-Clients mit einem AOO-Server verbinden und einer bestimmten Gruppe als User beitreten, werden sie über alle aktuellen Gruppenmitglieder informiert; sie werden auch benachrichtigt, wenn ein neuer User der Gruppe beitritt oder ein bestehender User die Gruppe verlässt. Gruppen und Benutzer können zusätzliche Metadaten enthalten, um maximale Flexibilität zu gewährleisten. Dies kann zum Beispiel von einer Online-Jamming-App genutzt werden, um Informationen über eine bestimmte Gruppe (Ort, Musikstil) und einen bestimmten Benutzer (Ort, Musikinstrument) anzuzeigen. Das Konzept der Servergruppen wurde durch das OSCgroups-Projekt  inspiriert.

© Christof Ressi

AOO-Server-Architektur.

AOO unterstützt sowohl das IPv4- als auch das IPv6-Protokoll. Clients kennen im Normalfall ihre öffentliche IPv4-Adresse nicht. Der fortschreitende Mangel an verfügbaren IPv4-Adressen führte zu einem breiten Einsatz von NAT, was die Herstellung von Peer-to-Peer-Verbindungen ernsthaft behindert. Es gibt verschiedene NAT-Traversal-Strategien, darunter das "UDP Hole Punching"; dieses wird von AOO verwendet, um IPv4-only-Clients über das Internet zu verbinden. Dies funktioniert in der Regel gut, es sei denn, ein oder mehrere Clients befinden sich hinter einem symmetrischen NAT; in diesem Fall ist es möglich, den Verkehr über spezielle Relay-Server bzw. den AOO-Server weiterzuleiten. Mit IPv6 hat jedes Gerät seine eigene, weltweit eindeutige und routbare IP-Adresse, womit NAT überflüssig wird. Da Firewalls jedoch unaufgeforderten eingehenden Verkehr standardmäßig blockieren, ist "Hole Punching" weiterhin erforderlich.

© Christof Ressi

UDP hole punching.

AOO-Peers können auch Nachrichten mit beliebigem Inhalt austauschen, bei Bedarf auch mit Zeitstempeln, um das relative Timing zu bewahren. Diese Nachrichten können entweder an einzelne Peers oder an ganze Gruppen gesendet werden. Sie können, falls gewünscht, auch zuverlässig zugestellt werden. Zu diesem Zweck implementiert AOO einen eigenen Mechanismus für die erneute Nachrichtenübertragung und Empfangsbestätigung. Für zustandsbehaftete („stateful“) Nachrichten ist die Zuverlässigkeit sehr wichtig. Man stelle sich vor, man möchte einen Schalter umlegen oder die nächste Szene aufrufen: wenn das Netz auch nur eine einzige Nachricht verwirft oder umordnet, kann das katastrophale Folgen haben! Ein Nachteil der zuverlässigen Nachrichtenübermittlung ist jedoch, dass verlorene Pakete nachfolgende Nachrichten blockieren, bis das fehlende Paket erneut gesendet wird. Dieses Phänomen ist auch als Head-of-Line-Blocking bekannt. Bei kontinuierlichen Datenströmen, wie etwa den Daten eines IMU-Sensors, sind Paketverluste oder die Umordnung von Paketen kein großes Problem, daher können solche Nachrichten auch unzuverlässig gesendet werden, um unerwünschte Verzögerungen zu vermeiden. Zuverlässige und unzuverlässige Nachrichten werden unabhängig voneinander gesendet und empfangen, so dass sie sich nicht gegenseitig blockieren können.

© Christof Ressi

Reliable and unreliable client messages.

Fazit

AOO ist eine neue Audio-Streaming- und Messaging-Lösung mit vielen möglichen Anwendungen in der Kunst und darüber hinaus. Die reichhaltige Funktionspalette erschließt neue, unkonventionelle Einsatzgebiete und regt dazu an, traditionelle Konzepte des Audio-Streamings zu hinterfragen und neu zu denken.

Schließlich möchte ich mich bei den folgenden Personen und Organisationen für ihre Unterstützung, ihre Ideen und ihr wertvolles Feedback bedanken: Winfried Ritsch, IOhannes M zmölnig, Roman Haefeli, José-Miguel Fernández, Jesse Chappell, IEM, IRCAM und anderen.