RoarAudio
RoarAudio ist ein Sound-System für alle POSIX konformen Betriebssysteme (GNU/Linux, *BSD und andere) unter aktiver Entwicklung. Es existieren auch experimentelle Schnittstellen zu anderen Systemen. RoarAudio kann als sogenanntes drop-in-replacement für alle gängigen Sound Server verwendet werden. Das heißt, dass RoarAudio diese ersetzen kann ohne das die Anwendungs Software ersetzt werden muss oder Veränderungen an ihr oder der Konfiguration (abgesehen von kleinen Änderungen) vorgenommen werden muss. Er ist als Ersatz für den Enlightened Sound Daemon (ESD, EsounD) entstanden und bietet viele zusätzliche Funktionen, z.B. für den Studio Betrieb.
Einleitung
Ein klassischer Sound-Server mischt Audio Daten, die von verschiedenen Applikationen auf einer Soundkarte abgespielt werden. RoarAudio erweitert dieses Konzept, indem es auch andere, sogenannte Output Streams als Soundkarte interpretieren kann. Unter anderem ist die Ausgabe als Dateie, Pipes oder Streaming zu einen (Web-)Streaming Server möglich. Ausserdem können Daten nicht nur von Applikationen bezogen werden. Die Input Streams sind auch in der Lage, Daten aus Dateien oder über das Netzwerk zu beziehen. Weitere Datenlieferanten können Soundkarten oder ISDN Adapter sein.
Ein weiterer Unterschied von RoarAudio zu herkömmlichen Sound-Servern: es werden bereits verschiedene komprimierte Codecs unterstützt, wie z.B. Vorbis, Speex, CELT u.a.
RoarAudio wartet mit einer sehr niedrige Latenz auf (zwischen < 1ms und 10ms). Die Netzwerkfähigkeit von RoarAudio gestattet es zudem, verschiedene Applikationen (Clients) dezentral auf anderen Rechnern auszuführen. Das heisst, diese müssen nicht auf dem gleichen Rechner installiert sein, auf dem RoarAudio läuft. Es ist auch möglich, die Applikationen (Clients) via IP oder DECnet mit dem Server zu verbinden.
Einteilung in Komponenten
RoarAudio Komponenten:
- Der Sound Server
- Der Sound Server verarbeitet die Anfragen der Clienten und mischt gegebenenfalls die (Audio-) Daten. Als Sound Server können für RoarAudio Zum Beispiel roard, µRoarD oder nrd zum Einsatz kommen.
- Die ClientBibliotheken
- Die Client-Bibliotheken sind Schnittstellen, die für die Kommunikation mit dem Sound-Server notwendig sind. Zusätzlich stellen die Bibliotheken zusätzliche Funktionen zur verfügung, wie z.B. das automatische Auffinden von Servern, die Ein-/Ausgabe-Abstraktion u.a. Zum Einsatz kommen hier vor allem libroar und µRoar.
- Client Applikationen
- Client-Applikationen sind in der Regel Dienstprogramme des Benutzers (Wie Mixer-GUIs) und Multimedia Programme.
- Kompatibilitäts Bibliotheken
- Diese Bibliotheken werden benutzt, um Applikationen die keine native Unterstützung für RoarAudio besitzen, einzubinden. Das geschieht meisst durch die Emulation von Bibliotheken anderer Sound-Systeme oder Server. Diese Bibliotheken sind der Hauptgrund, warum RoarAudio als drop-in-replacement angesehen werden kann und sind ein sehr wichtiger Teil des Projektes. Für eine Liste siehe Liste der Kompatibilitäts Biblotheken.
- Kompatibilitäts Binarys
- Hierbei handelt es sich um eine Sammlung von kleinen Dienstprogrammen. Diese kleinen Helfer laufen im Hintergrund von RoarAudio und sind z.B. in der Lage, andere Sound-Server oder Sound-Systeme zu emulieren. Siehe hierzu auch die Liste der Kompatibilitäts Binarys.
Erwähnt sei noch, dass in einen RoarAudio Sound-Server weitere Protokolle von anderen Sound-Servern implementiert werden können. Das gestattet eine nahezu vollständige Integration von Applikationen, die keine Kompatibilitätsbibliotheken besitzen und gestartet werden sollen. Siehe hierzu die Liste der unterstützten Protokolle.
Kompatibilität
RoarAudio bringt diverse Plugins sowie Kompatibilitäts-Layer (Bibliotheken + Binarys) mit. Zu den Wichtigsten zählt die libroaresd. Damit können Applikation die die EsounD Unterstützung besitzen, RoarAudio benutzen. Diese Bibliotheken sind Binär-kompatibel. Es ist also nicht notwendig die Applikation erneut aus dem Source-Code heraus zu kompilieren. Weitere Plugins sind unter anderem für MPlayer, XMMS und gstreamer (GNOME) verfügbar. An einem Ersatz für aRts (KDE) wird gearbeitet.
Lizensierung
Im Moment ist das Projekt unter der GPLv3 und LGPLv3 lizensiert. Aufgrund verschiedener Lizenzprobleme unterliegen alle Binär Versionen der GPLv3 Lizenz. Es wird angestrebt, die Lizensierung auf eine weniger restriktive Lizenz umzustellen.
Um Programmen mit nicht kompatibler Lizenz den Zugriff auf RoarAudio zu ermöglichen, wurde µRoar geschrieben. Es handelt sich um eine kleine Bibliothek die den Zugriff auf win32 ermöglicht.
Entwicklung
Die Entwicklung ist stark Community basierend. Das bedeutet, dass viele Menschen an dem Projekt arbeiten und ihren Teil beitragen. Wenn du auch an der Entwicklung mitarbeiten möchtest, kannst du Kontakt über den IRC-Channel des Projektes aufnehmen oder die Mailinglisten nutzen. Über diese Wege findet zudem die Hauptkommunikation der Entwickler des Projekts statt.
Ein weiteres Merkmal, das RoarAudio von anderen Sound Systemen abgrenzt, ist das das RoarAudio Protokoll-Zentrisch und nicht Software-zentrisch entwickelt wird. Das heisst, dass zuerst das Protokoll und danach die Software entwickelt und geschrieben wird um die Spezifikationen umzusetzen. DAmit kann RoarAudio mit mehreren Server und Client-Biblotheken gleichzeitig arbeiten.
Release Zyklus
Künftig soll circa einmal im Monat ein kleines Release veröffentlicht werden. Dabei kann es sich um eine Beta, eine RC oder ein Major Release handeln. Begonnen wird Beta Releases. Sollte sich der Entwicklungsstand einem neuen Major Releases nähern, werden RC Releases veröffentlicht. Ein Major Release wird nach dem Abschluss aller Entwicklungsarbeiten an der Version abgeschlossen sind. Ein Major-Release kann man an der Versionsnummer erkennen. Diese hat keine Zusätze, wie z.B. 0.2, 0.3, 1.0. Das Major Release wird bei der Entwicklung in aller Regel als RC Release geführt.
Zusätzlich zum Hauptzyklus gibt es den Pre-Release Zyklus. Dieser dient der Qualitätssicherung. Ist z.B. das Entwicklerteam der Ansicht, dass ein Release veröffentlicht werden kann, so wird dieses vorbereitet und als Release mit Pre-Release-Kennung (-prX) veröffentlicht. Nun kann jeder Entwickler mit einer Frist, welche in der Bekanntgabe steht und meist 2 Tage beträgt, Einspruch gegen das Release einlegen. Ist das der Fall, entscheidet das Entwicklerteam über das weitere Vorgehen. In der Regel wird das Problem behoben und ein neues Pre-Release veröffentlicht. Während des Pre-Release Zyklusses gilt ein sogenanntes 'feature freeze'. Das heißt, dass keine neuen Funktionen aufgenommen werden dürfen. Dieser Vorgang soll den Paket-Testern die Möglichkeit geben, die neue Version zu testen und eventuelle Probleme an die Entwickler zu melden.
Projekt Geschichte
Das Projekt hatte am 31 August 2008 sein Initialrelease.
Projekt Meilensteine
- 2008-08-31
- Erstes öffentliches Release (v. 0.1)
- 2009-02-04
- Erstes Release der 0.2er Versionen (v. 0.2beta0)
- Hier wurde auch das Versionierungs Schema umgestellt
- 2009-05-21
- Release von Version 0.2
- 2009-09-06
- Erste kommerzielle verwendet mit dem Programm roarphone (v. 0.3beta0)
- 2010-06-11
- Einführung des Prerelease Verfahrens zur Qualitätssteigerung
- 2010-08-22
- Release von Version 0.3
Architektur
RoarAudio ist in mehrere unabhänigen Komponenten eingeteilt. Diese werden intern mit einem weitgehend Objekt Orientierten Design umgesetzt.
Das RoarAudio Protokoll
Das RoarAudio Protokoll ist in mehre Layer aufgeteilt: das Message Layer, das Command Layer und das Daten Layer.
Das Message Layer dient dazu Einzelne Nachrichten unabhänig von ihrem Inhalt zu behandeln. Dies dient zum Beispiel dazu das auch Nachrichten von bekanntem Type korrekt behandelt werden können. Dieses Layer erzeugt um die Inhalte einen Rahmen der unter anderem die Kennung des Befehls und die Länge der folgenden Daten beinhaltet. Es ist das Unterste Layer im RoarAudio Protokoll Stack.
Das nächst höhere Layer ist das Command Layer. Es beinhaltet die Befehle die zwischen Server und Klient getaucht werden und die Interpretation dieser.
Das Letzte Layer ist das Daten Layer. Hier liegen die eigentlichen Audio daten.
Alle Layer haben (in der Regel) eine Versionsnummer. Durch diese können alle Layer unabhänig von einander verändert werden ohne das die darunter oder darüber liegenden Layer betroffen sind.
RoarAudio im OSI Modell
| Schicht | Schicht Name | Objekte | Modul(e) | Beispiele |
|---|---|---|---|---|
| 7 | Anwednung | Stream | Mixer | Musik Stück |
| 6 | Präsentation | Codec | Codec Filter | PCM, A-Law, Vorbis, ... |
| 5 | Sitzung | Client, Message | Steuer Logik | Befehle: QUIT, NEW_STREAM, ... |
| 4 | Transport | VIO, Socket | IO | TCP, NSP, ... |
| 3 | Netzwerk | VIO | IO | IP, DRP, ... |
| 2 | Sicherung | Ethernet, RS232, I2C, CAN, ... | ||
| 1 | Physikalisch | Kupfer, LWL, Funk |
Unterthemen
Weblinks
Offizielle Webpräsenz „RoarAudio”
Dieser Artikel ist leider sehr kurz. Also: Sei mutig und mache aus ihm bitte einen guten Artikel, wenn du mehr zum Thema „RoarAudio” weißt.
