RoarAudio

Dieser Artikel beschreibt das Software-Paket RoarAudio und geht nicht ausreichend auf alternative Implementierungen ein und sollte daher überarbeitet werden. Siehe auch Diskussionsseite.

RoarAudio Logo

RoarAudio ist ein Sound-System für alle POSIX konformen Betriebssysteme (GNU/Linux, *BSD und andere) unter aktiver Entwicklung. Es existieren auch experimentelle Ports zu anderen Systemen. RoarAudio kann als so genanntes 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 Ihrer Konfiguration (abgesehen von Trivial-Änderungen) vorgenommen werden muss. Er ist als Ersatz für den Enlightened Sound Daemon (ESD, EsounD) entstanden und bietet viele zusätzliche Funktionen zum Beispiel 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, so genannte Output Streams, als Soundkarten haben kann. Unter anderem sind Dumps in Dateien, Pipes oder Streaming an einen (Web-)Streaming Server möglich. Auch ist es möglich Daten nicht nur von Applikationen zu beziehen sondern die Input Streams auch Daten aus Dateien oder über das Netzwerk beziehen zu lassen. Ebenso ist es möglich Daten über Geräte wie Soundcards und ISDN Adaptern zu beziehen.

Ein weiterer Unterschied zu herkömmlichen Sound-Servern ist, dass RoarAudio auch verschiedene komprimierte Codecs unterstützt wie Vorbis, Speex, CELT und andere.

RoarAudio ist dafür entworfen eine sehr niedrige Latenz aufzuweisen. Sie liegt zwischen < 1ms und 10ms. Auch besteht volle Netzwerk-Transparenz. Dass heißt das Applikationen nicht zwangsweise auf dem selben Rechner laufen müssen wie RoarAudio selbst. Die Applikationen (Clients) können sich auch via IP oder DECnet auf den Server miteinander verbinden.

Einteilung in Komponenten

RoarAudio besteht aus mehren Komponenten die auf einander Aufbauen:

Der Sound Server

Der Sound Server verarbeitet die anfragen der Klienten und mischt gegebenenfalls die (Audio-) Daten. Als Sound Server können für RoarAudio Zum Beispiel roard, µRoarD oder nrd zum Einsatz kommen.

Die Klient-Bibliotheken

Die Klient-Bibliotheken bieten den Klienten eine Schnittstelle an über die sie mit den Sound Servern kommuniziren können. Auch können weitere Funktionen angeboten werden wie Automatisches auffinden von Servern, Ein-/Ausgabe-Abstraktion und ähnliches welches die Kommunikation Erleichtert. Zum Einsatz kommen hier vor allem libroar und µRoar.

Klient Applikationen

Die Klient Applikationen sind in der Regel Dienstprogramme dies Benutzers (Wie Mixer-GUIs), sowie Multimedia Programme.

Kompatibilitäts Bibliotheken

Diese Bibliotheken dienen dazu Applikationen welche keine native Unterstützung für RoarAudio besitzen eben diese an zu bieten. Dies geschieht in den meisten fällen in dem sie Bibliotheken anderer Sound Systeme und Sound Server emulieren. Diese Bibliotheken sind der Hauptgrund warum RoarAudio als drop-in-replacement angesehen werden kann und ein 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 die Dienstprogramme anderer Sound Server und Sound Systeme emulieren und im Hintergrund auf die Dienstprogramme welche RoarAudio zur Verfügung stellt zurückgreifen. Siehe hierzu auch die Liste der Kompatibilitäts Binarys.

Auch sei erwähnt das ein RoarAudio Sound Server weitere Protokolle von anderen Sound Servern implementieren kann. Dadurch wird nahe zu der komplette über bleibende Bereich der Applikationen die nicht mit Kompatibilitäts Bibliotheken gestartet werden können unterstützt. 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, welche es jeder Applikation, die EsounD Unterstützung besitzt, ermöglicht RoarAudio zu nutzen. Da diese Bibliotheken Binär-kompatibel sind ist es nicht nötig 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. Auf Grund diverser Lizenz Probleme unterliegen alle Binär Versionen der GPLv3. Es besteht das Streben die Lizensierung auf eine weniger strikte Lizenz umzustellen.

Um Programmen unter nicht kompatibler Lizenz den Zugriff auf RoarAudio zu ermöglichen wurde µRoar geschrieben. Es handelt sich hierbei um eine minimalistsche Bibliothek welche den Zugriff, vor allem auf win32, ermöglicht.

Entwicklung

Die Entwicklung ist sehr stark Community basierend. Das heißt das viele Individuen daran beteiligt sind und auch jeder der möchte Teile beitragen kann. Die Kommunikation findet primär auf den Mailinglisten des Projekts sowie im IRC Channel des Projektes statt.

Ein weiteres Merkmal, das auch von anderen Sound Systemen abgrenzt, ist das RoarAudio Protokoll-Zentrisch und nicht Software-zentrisch entwickelt wird. Dies bedeutet das in erster Linie das Protokoll das verwendet wird entwickelt wird und in einem zweiten Schritt dann Software geschrieben wird die diese Spezifikationen umsetzt. Dies ist auch der Grund warum für RoarAudio mehre Server und Klient-Bibliotheken möglich und auch existent sind.

Release Zyklus

Das Projekt hat sich das Ziel gesetzt etwa einmal pro Monat ein Release zu machen. Dabei kann es sich entweder um ein Beta, ein RC oder ein Major Release handeln. Zu beginn wird mit Beta Releases angefangen. Sollte sich der Stand den ziehen des nächsten Major Releases nähern so werden RC Releases getätigt. Sobald das Ziel des des Major Releases erreicht sein wird diese gemacht. Dies erkennt man daran das die Versionsnummer keinen Zusatz trägt (Beispiel: 0.2, 0.3, 1.0). Das Major Release wird bei der Entwicklung in aller Regel als RC Release geführt.

Zu diesem Hauptzyklus wurde ein weiterer Zyklus eingefürt: der Pre-Release Zyklus. Dieser dient dazu die Qualität der Releases zu steigern. Sollte das Entwicklerteam der Meinung sein das sie ein Release durchführen können so wird dies vorbereitet und als Fertiges Release mit einer Pre-Release-Kennung (-prX) versehen veröffentlicht. Nun hat jeder das Recht binnen einer Frist (welche in der Bekanntgabe steht, meist aber 2 Tage beträgt) Einspruch gegen das Release ein zu legen. Sollte dies geschehen entscheidet das Entwicklerteam über das weitere Vorgehen. In aller Regel wird das Problem beseitigt und ein neues Pre-Release veröffentlicht. Während des Pre-Release Zyklusses gilt so genanntes 'feature freeze'. Das heißt das keine neuen Funktionen aufgenommen werden dürfen. Dieser Vorgang soll dazu dienen das als Beispiel Paket-Maintainer die neue Version testen können und etwaige Probleme Rückmelden können.

Projekt Geschichte

Das Projekt hatte am Son den 31 August 2008 sein initialen Release.

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

• Installation und Einrichtung
• Programmieren
  • Intro
  • Simple
  • Stream
  • VIO
  • VS
• Vorlage Vortrag (1h)
• Vortrag
  • Erster Vortrag
  • Grundlagen der digitalen Signalverarbeitung
  • Grundlagen der digitalen Signalverarbeitung (UKW-Tagung 2013)
  • Irgendwas rund um RoarAudio
  • Programmieren mit RoarAudio VS
  • RoarAudio und der RoarAudio PlayList Daemon
  • UUGRN 0x0A
  • Was ist RoarAudio

RAUM (Media Container)

µRoar (Bibliothek)

RoarAudio PlayList Daemon (Player Backend)

Romie (Web basierender Player)

RoaringBox

Weblinks

Offizielle Webpräsenz „RoarAudio”

UUGRN-Wiki verbessern („Stub”)

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.