Bearbeiten von „RoarAudio“
Aus UUGRN
Warnung: Du bist nicht angemeldet. Deine IP-Adresse wird bei Bearbeitungen öffentlich sichtbar. Melde dich an oder erstelle ein Benutzerkonto, damit Bearbeitungen deinem Benutzernamen zugeordnet werden.
Die Bearbeitung kann rückgängig gemacht werden. Bitte prüfe den Vergleich unten, um sicherzustellen, dass du dies tun möchtest, und speichere dann unten deine Änderungen, um die Bearbeitung rückgängig zu machen.
| Aktuelle Version | Dein Text | ||
| Zeile 13: | Zeile 13: | ||
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, [[Pipe]]s 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 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, [[Pipe]]s 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 | + | Ein weiterer Unrterschied von RoarAudio zu herkömmlichen Sound-Servern: es werden bereits verschiedene komprimierte [[Codec]]s 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. | '''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. | ||
| Zeile 23: | Zeile 23: | ||
: 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. | : 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 ClientBibliotheken''' | ||
| − | : Client-Bibliotheken sind Schnittstellen, die für die Kommunikation mit dem Sound-Server notwendig sind. | + | : 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''' | ||
: Client-Applikationen sind in der Regel Dienstprogramme des Benutzers (Wie Mixer-GUIs) und Multimedia Programme. | : Client-Applikationen sind in der Regel Dienstprogramme des Benutzers (Wie Mixer-GUIs) und Multimedia Programme. | ||
| Zeile 34: | Zeile 34: | ||
== Kompatibilität == | == Kompatibilität == | ||
| − | '''RoarAudio''' bringt diverse Plugins sowie Kompatibilitäts-Layer (Bibliotheken + Binarys) mit. Zu den | + | '''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 == | == Lizensierung == | ||
| − | Im Moment ist das Projekt unter der GPLv3 und LGPLv3 | + | 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 | + | 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 == | == Entwicklung == | ||
| − | Die Entwicklung ist stark Community basierend. Das | + | 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 | + | 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 === | === 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 == | == Projekt Geschichte == | ||
| − | Das Projekt hatte am 31 August 2008 sein | + | Das Projekt hatte am Son den 31 August 2008 sein initialen Release. |
=== Projekt Meilensteine === | === Projekt Meilensteine === | ||
