RoarAudio/Vorlage Vortrag (1h): Unterschied zwischen den Versionen

Aus UUGRN
(→‎Konzepte und Architektur: Update der anzahl der zeilen, keine soruces disskutiren, cf gekuertzt)
K (→‎Vorführung: +Audacious, innerwikilinks)
 
(19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
<div style="background:#fee846;text-align:left; color: #000;font-weight:bold;font-size:125%;margin: 0px 5px 0px 0; padding: 4px 4px 4px 14px;">Was ist RoarAudio?</div>
<div style="background:#fee846;text-align:left; color: #000;font-weight:bold;font-size:125%;margin: 0px 5px 0px 0; padding: 4px 4px 4px 14px;">Was ist RoarAudio?</div>
<div style="margin: 0 5px 5px 0; padding: 1em 1em 1em 1em; border: 1px solid #fee846; background-color:#fffdf5;">
<div style="margin: 0 5px 5px 0; padding: 1em 1em 1em 1em; border: 1px solid #fee846; background-color:#fffdf5;">
; Ziel : ein Vortrag über [[RoarAudio]] und die Realtime Audio mixing Problematik vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
; Ziel : ein Vortrag über [[RoarAudio]] vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
</div>
</div>


Zeile 10: Zeile 10:


== Abstrakt ==
== Abstrakt ==
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.
RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch für den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.


== Vortrag ==
== Vortrag ==
=== Was ist RoarAudio? ===
=== Was ist RoarAudio? ===
{{Vortrags Zeit|5}}
RoarAudio ist ein Soundserver.
RoarAudio ist ein Soundserver.


Zeile 40: Zeile 42:
* Verzerrungen im Frequenzgang
* Verzerrungen im Frequenzgang
* Klirren
* Klirren
* Quantisierungsrauchen
* (Quantisierungsrauchen (DAC->ADC))
* Effekte durch asynchrone Abtastung


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


RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.
RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.
<s>
=== 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 in eine Datei codiert wurden in 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
</s>


=== Was hebt RoarAudio hervor? ===
=== Was hebt RoarAudio hervor? ===
Zeile 66: Zeile 52:


==== Codecs ====
==== Codecs ====
RoarAudio zeichnet sich dadurch aus daß er zusätzlich zu PCM Rohdaten auch höher Codecs versteht. Dies hat mehre Vorteile:
{{Vortrags Zeit|4}}
 
RoarAudio zeichnet sich dadurch aus daß er zusätzlich zu [[PCM]] Rohdaten auch höher [[Codec]]s versteht. Dies hat mehre Vorteile:


* Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio als Background Stream abzuspielen.
* Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio als Background Stream abzuspielen.
* Es ist dem Server möglich direkt Streaming-Server wie [[icecast]] zu bedienen. 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.
* Es ist dem Server möglich direkt Streaming-Server wie [[icecast]] zu bedienen. 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 es nur mit stark komprimierenden Codecs möglich über die dem Heim-Anwender zur Verfügung stehenden Schmalband-Anschlüsse Audio entweder von Client zu Server oder zwischen zwei Servern auszutauschen. Auch eine Kopplung über ISDN Kanäle ist so möglich.
* Auch ist es nur mit stark komprimierenden Codecs möglich über die dem Heim-Anwender zur Verfügung stehenden Schmalband-Anschlüsse Audio entweder von Client zu Server oder zwischen zwei Servern auszutauschen. Auch eine Kopplung über ISDN Kanäle ist so möglich.


==== Netzwerk-Transparenz ====
==== Netzwerk-Transparenz ====
{{Vortrags Zeit|2}}
RoarAudio ist Netzwerks-transparent, das heißt das Applikationen keinen Unterschied sehen zwischen Verbindungen mit einer lokalen Instanz oder einer auf einem anderen Rechner.
RoarAudio ist Netzwerks-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.
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. Des weiteren besteht die Möglichkeit Server im Lokalen Netzwerk mittels [[OpenSLP]] automatisch zu finden (so genanntes [[ZeroConf]]).


==== Background Streams ====
==== Meta Daten ====
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 einzuspielen wie beispielsweise in einem Kaufhaus. Auch Webradio Streams werden hier unterstützt.
{{Vortrags Zeit|2}}


==== Meta Daten ====
RoarAudio hat die Fähigkeit auf per Stream Basis Metadaten ab zu legen. Die Mechanismen sind denen von [[Vorbis Comments]] nachempfunden können aber prinzipiell mehr. Einiges davon ist allerdings noch nicht vollständig implementiert.
RoarAudio hat die Fähigkeit auf per Stream Basis Meta Daten ab zu legen. Die Mechanismen sind denen von Vorbis Comments nachempfunden und können prinzipiell mehr. Einiges davon ist allerdings noch nicht vollständig implementiert.


Es besteht neben dem manuellen Setzen die Möglichkeit daß ein Player sie setzt und das ''roard'' sie selbstständig setzt. Im letzteren Falle werden diese von verschiedenen anderen Streams zusammen gesetzt. Dies kann nützlich sein um automatisch beim Streaming die Metadaten von einem Player zu übernehmen um die Titel-Informationen weiter zu führen. Manuelles setzen mag als Beispiel interessant sein um den Sendernamen zu setzen.
Es besteht neben dem manuellen Setzen die Möglichkeit daß ein Player sie setzt und das ''roard'' sie selbstständig setzt. Im letzteren Falle werden diese von verschiedenen anderen Streams zusammen gesetzt. Dies kann nützlich sein um automatisch beim Streaming die Metadaten von einem Player zu übernehmen um die Titel-Informationen weiter zu führen. Manuelles setzen mag als Beispiel interessant sein um den Sendernamen zu setzen.


==== Virtual IO ====
==== Kompatibilitäts Bibliotheken und Binarys ====
''(gestrichen)''
{{Vortrags Zeit|4}}


==== Kompatibilitäts Bibliotheken ====
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''
''Viele Programme haben keine Unterstützung für RoarAudio, was nun?''


Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken.
Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken und Kompatibilitäts-[[Binary]]s.
Diese stellen Bibliotheken dar welche binär-kompatibel andere Audio Systeme emulieren.
Kompatibilitäts-Bibliotheken stellen Bibliotheken dar 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 entsprechenden Bibliothek.
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 entsprechenden 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.
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]], [[aRts|KDEs aRtsc]], [[PulseAudio]] und [[sndio|OpenBSD sndio]]. Zusammen mit den existierenden Plugins deckt dies nahezu den vollständigen Player Markt für GNU/Linux und BSD ab.


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.
Die Kompatibilitäts-Binarys funktionieren im Grunde gleich wie die Bibliotheken: Sie werden anstatt der Orginale installiert und leiten alle Anfragen weiter. Sie werden vorallem für Kompatibilität mit (Shell-)[[Skript]]en benötigt.
 
Neben dem direktem Installieren dieser Kompatibilitäts Layer lassen sie sich auch getrennt installieren und bei bedarf mittels des Programms ''roarify'' aktivieren:
$ roarify myapp ...


===== Welche Schnittstelle für was? =====
===== Welche Schnittstelle für was? =====
{| class="wikitable"
Aktuelle liste hier entnehmen: [[RoarAudio/Installation_und_Einrichtung#Kompatibilit.C3.A4ts_Layer|RoarAudio/Installation und Einrichtung Sektion Kompatibilitäts Layer]].
! Interface
! Beispiel Applikationen
|-
| libroar
| roaraudio-tools, XMMS, mplayer, (xine)
|-
| EsounD
| GNOME, KDE, XMMS, xine, Amarok, wine,... (177 weitere unter Debian Stable)
|-
| libao
| vorbis-tools, FLAC tools, mpd, mpg321, gnomoradio, somaplayer
|-
| aRts(c) (KDE)
| Player mit aRts support: mplayer, xine; kwave, kaudiocreator,...
|-
| PulseAudio
| Ein paar Programme, die meisten über Plugins. (nicht viel unter Debian Stable)
|-
| YIFF
| y-tools
|-
| gstreamer
| GNOME, Alle GNOME Player. Dieverse andere.
|-
|}


=== Konzepte und Architektur ===
=== Konzepte und Architektur ===
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa 37 tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).
{{Vortrags Zeit|1}}
 
RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa &lt;&lt;&lt;aktueller wert hier einsetzen&gt;&gt;&gt; tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).


==== Clients und Streams ====
==== Clients und Streams ====
{{Vortrags Zeit|5}}


Vor allem wichtig und nach Außen hin sichtbar sind die Client und Stream Objekte.
Vor allem wichtig und nach Außen 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 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 dar. 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. Er lässt sich durch ''attachen'' wechseln. Dies kommt zum Einsatz um Hintergrund-Streams zu ermöglichen.
Ein Stream Objekt stellt einen eigentlichen Audio Datenstrom dar. Dieses Objekt beinhaltet diverse Informationen über den Datenstrom: Informationen wie 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 roard selbst sein kann. Er lässt sich durch ''attachen'' wechseln. Dies kommt zum Einsatz um Hintergrund-Streams zu ermöglichen.


Bei jedem Audio Datenstrom der in den roard hinein oder heraus fließt handelt es sich um einen Stream. Dies schließt Datenströme zu Geräten wie Soundcards mit ein. Hierdurch ist eine maximale Flexibilität gegeben.
Bei jedem Audio Datenstrom der in den roard hinein oder heraus fließt handelt es sich um einen Stream. Dies schließt Datenströme zu Geräten wie Soundcards mit ein. Viele andere Soundserver behandeln Soundcards getrennt von den Streams der Clients. Hier unterscheidet sich RoarAudio deutlich. Die strickte Gleichbehandlung aller Datenströme in RoarAudio sorgt für eine maximale Flexibilität.


==== Driver ====
==== Driver ====
{{Vortrags Zeit|2}}
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, 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.
Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, 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.


==== Codecfilter ====
==== Codecfilter ====
{{Vortrags Zeit|2}}
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere 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.
Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere 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.


=== Probleme des Realtime Audio Mischens ===
=== Sonstiges ===
Beim Mischen in Realtime kommen zu den Problemen, die beim normalen Mischen von Audio auftreten, noch weitere hinzu.
{{Vortrags Zeit|0}}
 
Die wichtigsten Probleme sind:
 
* Resampling - Wenn nicht alle Streams dieselbe Abtastfrequenz 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 schnell sind und welche die gut sind. Muss man in Realtime resampeln so muss man vor allem schnell sein, will aber auch noch möglichst gut sein. Viele Soundserver behalten schlichtweg die Pegel entsprechend der neuen Abtasterate länger oder kürzer bei (s.g. zoh - Zero Order Hold). Dies erzeugt Rechteck Signale welche wiederum diverse Oberwellen erzeugen. RoarAudio setzt hier Polynomapproximation dritten Grades ein. Dies reduziert die Oberwellen schon deutlich dank leichter Tiefpass Eigenschaft.
* Da nicht für den gesamten Titel der Amplituden-Gang bestimmt werden kann ist es möglich daß es zu sogenanntem Clipping kommt. Clipping bezeichnet das Problem, daß 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 einen ReplayGain einzubeziehen. Dieser kann das Clipping zwar auch nicht komplett verhindern aber der Soundserver kann besser abschätzen wie die Gefahr für Clipping ist und 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 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.
* <s>Werden Signale mit verschiedenen Pegeln gemischt so kann es sinnvoll sein mit der Breite der Ausgangs-Samples hoch zu gehen. Als Beispiel: wenn zwei Signale mit je 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 eine 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.</s>
* <s>Einige Formate sind nicht Frame basierend. Dies sind vor allem MIDI Formate. Hier kann es passieren daß die Synchronisation zwischen diesen Streams und den anderen sich an Frame-Grenzen 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.</s>


==== Problem: Lokale Synchronität ====
Die wichtigsten Störfaktoren sind:
* Wie jede Hardware besitzen Soundkarten eine Verzögerung. Das heißt daß sie eine gewisse Zeit brauchen zwischen Erhalt von Daten und deren Ausgabe. Diese Zeit liegt im Bereich von wenigen Millisekunden (z.B. Studio Karten) und kann bis in den Bereich von mehren hundert Millisekunden gehen (z.B. 2.5 Euro USB Karten von $SUPERMARKT), je nach Karte. Die meisten Karten bieten aber eine Möglichkeit abzufragen wo sie gerade in ihrem Puffer sind. Wie dies genau funktioniert ist von Karte zu Karte unterschiedlich. Der Treiber der Karte ist dafür zuständig diese Funktionen an höhere Interfaces (OSS, alsa, sndio,...) weiterzureichen und den Applikationen zur Verfügung zu stellen.
* Neben dem Delay in der Hardware erzeugen selbstverständlich auch der Kernel und die Treiber eine weitere Verzögerung. Dies passiert aus vielen Gründen: Der Programmcode muss natürlich erst einmal ausgeführt werden. Auch werden Interupts nicht unbedingt sofort bearbeitet (zum Beispiel weil gerade ein anderer, höherwertiger bearbeitet wird).
* Die nächste Schicht, die Sound APIs, erzeugen auf ähnliche Weise weitere Delays. Hier kommt dazu das viele mit relativ großen Puffern arbeiten (Beispielsweise EsounD mit 0.28sec - im Vergleich zu roard mit Standard Puffer von 0.01sec). Die Puffergröße ist in dem meisten Fällen die kleinste Einheit in der Synchronität gewährleistet werden kann.
* Da die meisten Systeme (alle auf denen RoarAudio läuft) Multitasking betreiben stellt sich ein weiteres Problem: Der entsprechende Prozess muss eine Zeitscheibe bekommen bevor er reagieren kann. Läuft ein anderer Prozess gerade so muss er potentiell warten. Auf den meisten POSIX kompatiblem Systemen basiert das Multitasking zwar auf Ereignissen, sprich ein Prozess läuft so lange bis ein anderer ein Ereignis zu bearbeiten hat (keine feste Zeitscheiben-Länge), was dazu führt das dieses Problem ist nicht all zu groß ist. Aber es kann natürlich gerade ein anderer Prozess mit höherer Priorität laufen der ein anderes Ereignis bearbeitet und somit nicht vom Kernel unterbrochen wird.
* Unsynchrones clocking
==== Problem: Netzwerk Synchronität ====
* lag
* jitter
* Netzwerk Implementierungen
==== Lösungsansätze ====
{{Vortrags Zeit|10}}
* '''Ignorieren''' - Diverse Probleme lassen sich schlichtweg einfach ignorieren. Dies sind vor allem Probleme die sich statistisch über die Zeit aufheben. Ist diese Strategie möglich so sollte sie verfolgt werden im Sinne von KISS (Keep It Small and Simple). Sie kann natürlich auch extrem daneben liegen und man sollte sich um eine echte Lösung bemühen.
* '''TOS''' - Setzen des TOS (Type Of Service) Feldes bei IP mag helfen. Viele Backbone Provider ignorieren dieses Feld zwar aber im LAN kann es durchaus helfen. Gerade bei anderer starker, lang packetiger Kommunikation zwischen dem eignen und dem Ziehl Rechner (file transfers).
* '''QoS''' - Benutzung von QoS (Quality of Service) kann im Backbone Bereich die Latenz erheblich senken da man das Puffer-Verhalten der Geräte beeinflusst. Der Nachteil ist, daß hierzu Unterstützung da sein muss. mit IPv6 scheint sich hier aber einiges zu bessern.
* '''Geschickte Auswahl von Algorithmen und Protokollen''' - Die Auswahl der Algorithmen und Protokolle ist entscheidend. Für die meisten Aufgaben gibt es mehre mögliche Lösungen (''Viele Wege führen nach Rom''). Aber nicht alle sind gleich gut geeignet. Deswegen sollte hier eine sinnvolle Auswahl getroffen werden.
* '''Künstlicher Delay''' - Es besteht die Möglichkeit einzelne Streams oder Ereignisse künstlich leicht zu verzögern. Hierdurch kann ein Abgleich der Latenzen gemacht werden was dazu dient Synchronität herzustellen. Normalerweise werden alle Streams so lange verzögert bis sie eine ''künstliche'' Latenz gleich dem Stream haben der die höchste Latenz aufweist.
* '''Resampling''' - Sind mehre Clocks beteiligt oder kommen die Daten etwas zu schnell oder zu langsam kann man leichtes Resampling betreiben. Das heißt das das Signal künstlich gestaucht oder in die Länge gezogen wird. Geschieht dies nicht ruckartig kann das Gehör den Unterschied nicht wahrnehmen solange dieses Resamping nur in kleinen Bereichen passiert (je nach Literatur 2% bis 5%, Werte die größer sind als die Ungenauigkeit von Quarzen und somit geeignet sind um Clock driffting auszugleichen.).
=== Sonstiges ===
...
==== Win32 Port ====
==== Win32 Port ====
Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32, was den nahe-realtime Betrieb angeht, nicht zuverlässig genug. Zum anderen ist bei Win32 das Networking kein Teil des Kernels wie auf UNIX und POSIX Systemen: Es ist viel mehr teilweise im Userland. Dies hat zur Folge das zu jedem Zeitpunkt eine Applikation wissen muss von welchem Type ein Filehandle ist, da man Basis Funktionen wie read(), write(), close() nicht auf alle Filehandles anwenden kann. Vielmehr hat jeder Type von Filehandles seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig.
Es existiert ein experimenteller [[Win32]] Nativ-[[Port]] der RoarAudio Bibliotheken, des roards sowie einiger weiterer grundlegender Hilfsprogramme. Die Funktionalität ist hier aber recht eingeschenkt.


Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt.
RoarAudio ist des weiteren in [[Cygwin]] lauffähig. Unter Cygwin können deutlich mehr funktionen als nativ genutzt werden. Allerdings sind hier auch einige Einschränkungen vorhanden.


Im Moment existieren kleinere Patches die vielleicht irgendwann mal Basis Funktionalität mit sich bringen könnten. An ein roard für Win32 ist in absehbarer Zeit nicht zu denken.
Beide Optionen lassen sich nahezu beliebig kombinieren.


Allerdings laufen Teile von RoarAudio in Cygwin mehr oder minder gut. Viele Probleme treten hier auf aber es ist prinzipiell möglich es unter Cygwin zum Laufen zu bringen (außerhalb des nahe-realtime Betriebs).
Neben einigen Nativen Plugins besteht auch die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.
 
Es besteht aber die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.


==== MP3 ====
==== MP3 ====
Zeile 201: Zeile 139:


=== Querverweise ===
=== Querverweise ===
{{Vortrags Zeit|5}}
; [http://raum.keep-cool.org/ RAUM Media Container]
; [http://raum.keep-cool.org/ RAUM Media Container]
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
: Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
Zeile 211: Zeile 151:


=== Vorführung ===
=== Vorführung ===
{{Vortrags Zeit|30}}
{{Vortrags Zeit|15}}


* Allgemeiner Betrieb
* Allgemeiner Betrieb
Zeile 217: Zeile 157:
** roarvorbis/roarcatplay?
** roarvorbis/roarcatplay?
** roarctl
** roarctl
** xmms
** [[XMMS]] / [[Audacious]]
* Background Streams
** roarradio
* Kompatibilitäts Bibliotheken
* Kompatibilitäts Bibliotheken
** libroaresd:
** libroaresd:
*** <s>xmms</s>
*** [[Amarok]]
*** <s>mplayer</s>
*** Amarok


== Fragen ==
== Fragen ==
* ''immer gerne''
* ''immer gerne''


[[Kategorie:RoarAudio]]
[[Kategorie:Vortrag]]
[[Kategorie:Vortrag]]
[[Kategorie:Software]]
[[Kategorie:Software]]
[[Kategorie:Sound]]
[[Kategorie:Sound]]

Aktuelle Version vom 10. Januar 2010, 09:08 Uhr

Was ist RoarAudio?
Ziel
ein Vortrag über RoarAudio vor einem Unixpublikum mit keinen oder kaum Vorwissen zum Thema.
RoarAudio Logo

Der Autor[Bearbeiten]

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

Abstrakt[Bearbeiten]

RoarAudio ist ein Sound-Server für POSIX konformen Betriebssysteme (GNU/Linux, *BSD, Mac OS X und andere) unter aktiver Entwicklung. Er bietet gegenüber anderen Sound-Servern zusätzliche Funktionen für den Betrieb in kleinen Radio und TV Studios, aber auch für den Heimgebrauch. Dieser Vortrag soll einen Einblick in RoarAudio, seine Funktionalität und Funktionsweise sowie damit verbunden Problemstellungen auf einfachem Niveau bieten. Den Abschluss bildet eine Demonstration.

Vortrag[Bearbeiten]

Was ist RoarAudio?[Bearbeiten]

(Geplante Zeit: 5 Minuten)


RoarAudio ist ein Soundserver.

Was ist ein Soundserver[Bearbeiten]

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

Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen einzigen Datenstrom zu einer Zeit verarbeiten kann (Single Stream Soundcards). Sie stellen eine Art virtuelle Soundcard dar 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 für die Wiedergabe auf einer anderen Maschine. Dies beides kann auch RoarAudio.

Projekt Ziele[Bearbeiten]

(Geplante Zeit: 10 Minuten)


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 liefern das auch für den Heim-Anwender angemessen ist.

für Heim-Anwender[Bearbeiten]

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[Bearbeiten]

Wie oben schon angedeutet ist RoarAudio aber im Studio-Einsatz wesentlich interessanter: in einem klassischen 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 (DAC->ADC))

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

RoarAudio kommt hier als erst einmal reine Software-basierende Lösung. Natürlich ist es möglich über die Steuerschnittstellen auch externe Hardware anzuschließen. Hier gibt es auch Planungen, ein Hardware Frontend zu entwerfen das dann kostengünstig zu haben ist.

Was hebt RoarAudio hervor?[Bearbeiten]

Hier Sollen einige der besonderen Fähigkeiten von RoarAudio erläutert werden.

Codecs[Bearbeiten]

(Geplante Zeit: 4 Minuten)


RoarAudio zeichnet sich dadurch aus daß 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 als Background Stream abzuspielen.
  • Es ist dem Server möglich direkt Streaming-Server wie icecast zu bedienen. 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 es nur mit stark komprimierenden Codecs möglich über die dem Heim-Anwender zur Verfügung stehenden Schmalband-Anschlüsse Audio entweder von Client zu Server oder zwischen zwei Servern auszutauschen. Auch eine Kopplung über ISDN Kanäle ist so möglich.

Netzwerk-Transparenz[Bearbeiten]

(Geplante Zeit: 2 Minuten)


RoarAudio ist Netzwerks-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. Des weiteren besteht die Möglichkeit Server im Lokalen Netzwerk mittels OpenSLP automatisch zu finden (so genanntes ZeroConf).

Meta Daten[Bearbeiten]

(Geplante Zeit: 2 Minuten)


RoarAudio hat die Fähigkeit auf per Stream Basis Metadaten ab zu legen. Die Mechanismen sind denen von Vorbis Comments nachempfunden können aber prinzipiell mehr. Einiges davon ist allerdings noch nicht vollständig implementiert.

Es besteht neben dem manuellen Setzen die Möglichkeit daß ein Player sie setzt und das roard sie selbstständig setzt. Im letzteren Falle werden diese von verschiedenen anderen Streams zusammen gesetzt. Dies kann nützlich sein um automatisch beim Streaming die Metadaten von einem Player zu übernehmen um die Titel-Informationen weiter zu führen. Manuelles setzen mag als Beispiel interessant sein um den Sendernamen zu setzen.

Kompatibilitäts Bibliotheken und Binarys[Bearbeiten]

(Geplante Zeit: 4 Minuten)


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

Um dieses Problem zu lösen gibt es diverse Kompatibilitäts-Bibliotheken und Kompatibilitäts-Binarys. Kompatibilitäts-Bibliotheken stellen Bibliotheken dar 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 entsprechenden 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, PulseAudio und OpenBSD sndio. Zusammen mit den existierenden Plugins deckt dies nahezu den vollständigen Player Markt für GNU/Linux und BSD ab.

Die Kompatibilitäts-Binarys funktionieren im Grunde gleich wie die Bibliotheken: Sie werden anstatt der Orginale installiert und leiten alle Anfragen weiter. Sie werden vorallem für Kompatibilität mit (Shell-)Skripten benötigt.

Neben dem direktem Installieren dieser Kompatibilitäts Layer lassen sie sich auch getrennt installieren und bei bedarf mittels des Programms roarify aktivieren: 

$ roarify myapp ...
Welche Schnittstelle für was?[Bearbeiten]

Aktuelle liste hier entnehmen: RoarAudio/Installation und Einrichtung Sektion Kompatibilitäts Layer.

Konzepte und Architektur[Bearbeiten]

(Geplante Zeit: 1 Minuten)


RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. Er umfasst im Moment etwa <<<aktueller wert hier einsetzen>>> tausend Zeilen C. (EsounD kommt auf rund 15 tausend, PulseAudio 74 tausend und aRts auf 130 tausend).

Clients und Streams[Bearbeiten]

(Geplante Zeit: 5 Minuten)


Vor allem wichtig und nach Außen 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 dar. Dieses Objekt beinhaltet diverse Informationen über den Datenstrom: Informationen wie 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 roard selbst sein kann. Er lässt sich durch attachen wechseln. Dies kommt zum Einsatz um Hintergrund-Streams zu ermöglichen.

Bei jedem Audio Datenstrom der in den roard hinein oder heraus fließt handelt es sich um einen Stream. Dies schließt Datenströme zu Geräten wie Soundcards mit ein. Viele andere Soundserver behandeln Soundcards getrennt von den Streams der Clients. Hier unterscheidet sich RoarAudio deutlich. Die strickte Gleichbehandlung aller Datenströme in RoarAudio sorgt für eine maximale Flexibilität.

Driver[Bearbeiten]

(Geplante Zeit: 2 Minuten)


Ein Driver ist ein Objekt das eine Schnittstelle zur Verfügung stellt um externe Ressourcen anzusprechen, 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.

Codecfilter[Bearbeiten]

(Geplante Zeit: 2 Minuten)


Bei den Codecfiltern handelt es sich um ein Abstraktions Layer welches roard die Möglichkeit gibt höhere 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.

Sonstiges[Bearbeiten]

(Geplante Zeit: 0 Minuten)


Win32 Port[Bearbeiten]

Es existiert ein experimenteller Win32 Nativ-Port der RoarAudio Bibliotheken, des roards sowie einiger weiterer grundlegender Hilfsprogramme. Die Funktionalität ist hier aber recht eingeschenkt.

RoarAudio ist des weiteren in Cygwin lauffähig. Unter Cygwin können deutlich mehr funktionen als nativ genutzt werden. Allerdings sind hier auch einige Einschränkungen vorhanden.

Beide Optionen lassen sich nahezu beliebig kombinieren.

Neben einigen Nativen Plugins besteht auch die Möglichkeit einige Win32 Applikationen mittels pseudo Web Radio Streams anzubinden.

MP3[Bearbeiten]

  • Kein Streaming
  • Keine Meta Daten
  • Schlechte Qualität
  • Patente

Querverweise[Bearbeiten]

(Geplante Zeit: 5 Minuten)


RAUM Media Container
Für RoarAudio entwickelter Container, vor allem für Speex und CELT.
Icecast - Multimedia streaming server
Software für Webradio und WebTV streaming.
Xiph.Org Foundation
Organisation zur Entwicklung von freien Codecs.
SIP
Standard für VoIP - Internet-Telephonie.

Vorführung[Bearbeiten]

(Geplante Zeit: 15 Minuten)


  • Allgemeiner Betrieb
  • Kompatibilitäts Bibliotheken

Fragen[Bearbeiten]

  • immer gerne
Abgerufen von „https://wiki.uugrn.org/index.php?title=RoarAudio/Vorlage_Vortrag_(1h)&oldid=8998“