RoarAudio/Vortrag/Erster Vortrag

Was ist RoarAudio?

Ziel

ein Vortrag über RoarAudio und die realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.

RoarAudio Logo

Der Autor

Philipp ph3-der-loewe Schafft, Software Entwickler und Projekt Urheber.

Vortrag

Was ist RoarAudio?

RoarAudio ist ein Soundserver.

Was ist ein Soundserver

Ein Soundserver ist eine Programm das im Hintergrund Audio Daten mischt und das Ergebnis weiter leidet, meist an eine Soundcard.

Soundserver werden benötigt wenn wenn das unterliegende Audio Ausgabe-Gerät nur einen Datenstrom zu einer zeit verarbeiten kann (Single Stream Soundcards). Sie Stellen eine Art virtuelle Soundcard da zu der Programme wie Player ihre Daten schicken können um eine Simultane Ausgabe mit zum Beispiel Notify-Sounds von Chat Clients oder ähnlichem zu ermöglichen.

Sie bieten meist weitere Funktionen wie das Mischen unter berücksichtigung von verschiedenen Pegeln. Einige Soundserver ermöglichen auch die Benutzung von Netzwerken zur Übertragung von Audio Daten zur Wiedergabe auf einer anderen Maschine. Dies Beides kann auch RoarAudio.

Projekt Ziele

Das Projekt verfolgt im Prinzip das Ziel eine leistungsfähige Mischsoftware für den Studio Betrieb zur Verfügung zu stellen aber dennoch ein Produkt zu liefen das auch für den Heim-Anwender angemessen ist.

für Heim-Anwender

Heim-Anwender Teilen sich in zwei Gruppen auf: Die größere Menge interessiert es nicht wieso Musik aus den Lautsprechern kommt, Hauptsache sie tut es. Für diese Gruppe muss RoarAudio einfach out of the box funktionieren. Die Andere Gruppe sind Anwender die mehr machen wollen. Hier soll RoarAudio ein leistungsstarkes Backend sein das möglichst Ressourcen schonend alle gewünschten Funktionen anbietet.

Im Studio Betrieb

Wie Oben schon angedeutet ist RoarAudio aber im Studio Einsatz wesentlich interessanter: In einem klassisches Studio steht meist ein großes analoges Mischpult. Dies ist eine Wundervolle Sache solange man primär Analoge Eingänge braucht: Beispielsweise von einer Band. In Heutigen Radio- und Fernsehstudios kommen aber die meisten Kanäle aus dem Rechner oder anderen Digitalen Geräten wie CD Spielern.

Ein Analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl:

• Analoges Rauschen
• Verzerrungen im Frequenzgang
• Klirren
• Quantisierungsrauchen
• Effekte durch Asynchrone Abtastung

Eine Alternative wäre in einigen Fällen sicherlich ein Digital-Mischpult. Diese sind aber Meist sehr teuer.

RoarAudio kommt hier als erst einmal rein Software basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch Externe Hardware an zu schließen. Hier gibt es auch Planungen ein Hardware Frontend zu entwerfen das dann Kostengünstig zu haben ist.

Exkurs: Codecs und Container

Ein Codec ist eine Spezifikation (meist werden auch die Implementierungen Codec genannt) wie Rohdaten, im Falle von Audio meist PCM Daten, Als Datenstrom oder -block repräsentiert werden. Hierzu Zählt meist als primäres Kriterium die Kompression. Weitere Informationen wie Synchronisationsdaten können ebenfalls durch den Codec Spezifiziert sein werden aber meist im Container abgelegt.

Ein Container ist im Gegensatz zu einem Codec eine Spezifikation wie Daten die mittels Codecs codiert wurden in eine Datei oder einen Stream verpackt werden. Hierzu Zählen Dinge wie globale File-Magic, Angabe des Codecs, Meta Daten, Angaben über rate/bps/channels und Ähnliches.

Verschiedene Arten von Codecs

• Verlustfreie
• Verlustbehaftete
• Musik Codecs
• Sprach Codecs
• Niederlatenz Codecs

Was hebt RoarAudio hervor?

Hier Sollen einige der Besonderen Fähigkeiten von RoarAudio Erläutert werden.

Codecs

RoarAudio zeichnet sich dadurch aus das er zusätzlich zu PCM Rohdaten auch höher Codecs versteht. Dies hat mehre Vorteile:

• Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio im Als Background Stream ab zu spielen.
• Es ist dem Server möglich direkt Streaming-Server wie icecast zu Bedinen. Es ist keine weitere lange pipe nötig um Webradio zu senden. Dies verringert die Störanfälligkeit erheblich und verringert die Latenz da pipe-Puffer entfallen.
• Auch ist nur mit stark komprimierenden Codecs es möglich über dem Heim-Anwender zur Verfügung stehenden Schmalband Anschlüssen Audio entweder von Client zu Server oder zwischen zwei Servern aus zu tauchen. Auch eine Kopplung über ISDN Kanäle ist so möglich.

Netzwerk-Transparenz

RoarAudio ist Netzwerk transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer Lokalen Instanz oder einer auf einem anderen Rechner.

Zu diesem Zweck werden mehre Protokolle Unterstützt: UNIX Domain Sockets für Lokale Verbindungen sowie TCP/IP und DECnet für Verbindungen mit entfernten Rechnern. Auch existiert Support für verschiedene Proxy Typen.

Background Streams

Background Streams sind Streams die vom Server selbst bearbeitet werden und keinen Player benötigen um abgespielt zu werden. Dies kann zum Beispiel genutzt werden um Hintergrundmusik ein zu spielen wie Beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.

Virtual IO

...

Kompatibilitäts Bibliotheken

Viele Programme haben keine Unterstützung für RoarAudio, was nun?

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts Bibliotheken. Diese Stellen Bibliotheken da welche binär kompatibel andere Audio Systeme emulieren. Dazu müssen sie schlichtweg einfach anstelle der Bibliothek des entsprechen Systems installiert werden und Leiten dann alle anfragen an RoarAudio weiter. Dies geschieht natürlich nur im Rahmen des Funktionsumfang der entsprechen Bibliothek.

Die mit Abstand wohl wichtigste ist libroaresd welche das EsounD Interface Emuliert. das EsounD Interface wird von den allermeisten Applikationen unterstützt da es das wohl älteste Soundserver Interface ist. Es existiert seit 1998.

Weitere Kompatibilitäts Bibliotheken gibt es für das YIFF Sound System, KDEs aRtsc und PulseAudio. Zusammen mit den Existierenden Plugins deckt dies nahezu den vollständigen Player Markt fuer GNU/Linux und BSD ab.

Konzepte und Architektur

RoarAudio ist zwar in C geschrieben aber großen Teils Objekt orientiert.

Clients und Streams

Vor allem wichtig und nach Ausen hin sichtbar sind die Client und Stream Objekte. Ein Client Objekt verkörpert einen (Netzwerk) Client, zum Beispiel einen Player oder ein Steuerprogramm wie roarctl. Es kann auch Stream Objekte assoziiert haben (Beispielsweise im Falle von Abspielen von Musik).

Ein Stream Objekt stellt einen eigentlichen Audio Datenstrom da. Dieses Objekt beinhaltet diverse Informationen über den Datenstrom: Informationen wie der roard ihn auslesen kann, Sample Rate/Bits/Channels, Meta Daten und vieles mehr. Ein Stream gehört immer zu einem Client. Wobei der Client auch der roard selbst sein kann und sich durch attachen wechseln lest. Dies Kommt zum Einsatz um Hintergrund Streams zu ermöglichen.

Bei Jedem Audio Datenstrom der in den roard hinein oder heraus fliest handelt es sich um einen Stream. Dies schliest Datenströme zu Geräten wie Soundcards mit ein. Hier durch ist eine maximale Flexibilität gegeben.

Stream Typen

Es gibt diverse Verschiedene Stream typen. Die folgende Tabelle Beschreibt sie kurz:

Typ	Richtung	Beschreibung
Play	zu Server	Standard Typ: Eingehende Audio Daten.
Monitor	von Server	Hier werden die Aktuellen gemischten Audio Daten vom Server Abgefragt.
Filter	bidirektional	Dieser Stream Dient zum zwischenschalten von Filtern im Mixer
Output	vom Server	Dieser Stream geht an einen Driver Richtung Soundcard oder ähnlichem
Mixing	keine	Interne Audio Puffer genutzt zum Mischen der Daten
Bidir	bidirektional	Play und Monitor in einem.
Record	vom Server	Im Moment nicht Unterstützt.
Meta	Flag Abhänig	Im Moment nicht Unterstützt.
Internal	keine	Im Moment nicht Unterstützt.

Stream Flags

Ein Stream kann des weiteren Flags haben die sein Verhalten genauer bestimmen. Die Flags sind Hier zusammen gefasst:

Name	Beschreibung
Primary	Bei ende des Streams beendet sich roard selbst.
Output	Es wird Ein Output Driver für diesen Stream verwendet.
Source	Bei diesem Stream handelt es sich um eine Source.
Sync	Der Stream ist Synchron (mit Hardware bzw. seinem Ziel)
Meta	Ausgehende Streams mit diesem Flag beziehen ihre Meta Daten automatisch von Eingehenden Streams mit diesem Flag.

Driver

Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um Externe Ressourcen an zu sprechen die sich nicht der UNIX IO Philosophie entsprechend verhalten (Erweiterte Handshake zum Beispiel). Dies können Soundcards oder auch Streaming Server sein. Hierzu zählen als Beispiel der OSS (Open Sound System) und der libshout (Icecast) Treiber.

Sources

Eine Source ist an sich ein normaler Stream. Der unterschied besteht darin das roard selbst den Stream beim Starten Inizialiesiert. Neben Test Szenarien ist dies vor allem Hilfreich um sich die Audio Ausgabe eines anderen Rechners lokal zu Spiegeln.

Codecfilter

Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die möklichkeit gibt höhre Codecs zu sprechen wie etwa Ogg Vorbis. Einige Codecfilter können nur Lesen andere auch Schreiben. Wird ein Stream mit einem unterstützen Codec aufgebaut so wird automatisch eine Instanz eines passenden Codecfilters erzeugt. Sie verhalten sich somit weitgehend Transparent. Viele höheren Codec sind allerdings nicht in der Lage alle Stream Typen zu bedienen. Der Streamtype Filter wird am wenigsten Unterstützt da er ein exaktes Timing und Blocking Verhalten benötigt.

Probleme des Realtime Audio Mischens

Beim Mischen in realtime kommen zu den Problemen die beim Normalen Mischen von Audio auftreten noch weitere hinzu.

Die Wichtigsten Probleme sind:

• Resampling - Wenn nicht alle Streams die selbe Abtast Frequens haben müssen die betroffenen Streams auf die Abtastrate des Ausgangs umgerechnet werden. Hierzu gibt es diverse verfahren. Man kann sich das etwa wie das Skalieren eines Bildes vorstellen: Es gibt Filter die sind schnell und welche die sind gut. Muss man in realtime resampeln so muss man vorallem schnell sein, will aber auch noch möglichst gut sein. Viele Soundserver behalten schlichtweg die Pegel entsprechent der neuen Abtaste Rate länger oder kürzer bei. Dies erzeugt Rechteck Signale welche diverse Oberwellen Erzeugen. RoarAudio setzt hier Polynomapporximation dritten Gardes ein. Dies Reduziert die Oberwellen schon deutlich dank leichter Tiefpass Eigenschaft.
• Da nicht für den gesamten Titel der Amplituden-Gang bestimmt werden kann kann es passieren das es zu so genannten clipping kommt. Clipping bezeichnet das Problem das wenn die Summe der Amplituden aller Eingangssignale größer ist als der zulässige Wertebereich. In diesem falle wird das Ausgangssignal geclippt, sprich es wird auf den maximalen sich im zulässigen Wertebereich liegenden Wert herunter gesetzt. Dies lässt sich nicht vollkommen vermeiden aber durch geschickte Wahl des Mischverfahrens reduzieren. Es empfiehlt sich dennoch dem einen ReplayGain ein zu beziehen. Dieser kann das Clipping zwar auch nicht komplett verhindern aber der Soundserver kann besser abschätzen wie die gefahr für Clipping ist rechtzeitig reagieren.
• Vor allem beim Pegel umrechnen kommt es selbstverständlich zu Rechenungenauigkeiten. Um diese zu minimieren skaliert RoarAudio die Signale auf bis zu ihrer doppelten größe auf um Rechenungenauigkeiten zu vermeiden. bei einem 16 Bit Eingangssignal wird als Beispiel auf 32 Bit skaliert was zusätzliche 96dB Rauschabstand während der Umrechnung liefert.
• Werden Signale mit verschiedenen Pegeln gemischt so kann es Sinnig sein mit der Breite der Ausgangs Samples hoch zu gehen. Als Beispiel wenn zwei Signale mit 16 Bit mit den Pegeln 1 und 1/4 gemischt werden reduziert der Rauschabstand des zweiten Signals um 12dB. Man sollte überlegen auf 24 Bit am Ausgang zu wechseln. Die Allgemeine Regel lautet: für den Faktor 2 oder 6dB die ein Signal abgeschwächt wird braucht man am Ausgang ein Bit mehr. Wenn mal also ein Hintergrund Musik mit -48dB auf Sprache mischt (durchaus realistisch) muss man von 16 Bit am Ausgang auf 24 Bit hoch gehen um keinen Qualitäts-Verlust der Musik zu erhalten.
• Einige Formate sind nicht Frame basierend. Dies sind vor allem MIDI Formate Hier Kann es passieren das die Synchronisation zwischen diesen Streams und den anderen sich an Frame Grensen treffe. Dies kann zu unschönen Nebeneffekten führen. Manche Codecs sind auch nur in der lage auf gewisse Zeitraster Ende-Marken zu setzen was in unsauberen Enden mit Artefakten enden kann. IM realtime Bereich lässt sich dies nicht korrigieren und solche Codecs sollten vermieden werden.

Problem: Lokale Syncronität

Die wichtigsten Störfaktoren sind:

• Delay in in der Hartware
• Delay im Kernel und Treibern
• Delay in APIs
• Multitasking
• Unsyncrnes clocking

Problem: Netzwerk Syncronität

• lag
• jitter
• Netzwerk Implementierungen
• QoS

Querverweise

...

Vorführung

• Allgemeiner Betrieb
• Background Streams
• Kompatibilitäts Bibliotheken

Fragen

• immer gerne