Bearbeiten von „RoarAudio/Vortrag/Erster Vortrag“
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 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;"> | ||
Zeile 12: | Zeile 10: | ||
== Abstrakt == | == Abstrakt == | ||
− | + | ... | |
== Vortrag == | == Vortrag == | ||
Zeile 19: | Zeile 17: | ||
==== Was ist ein Soundserver ==== | ==== Was ist ein Soundserver ==== | ||
− | Ein Soundserver ist eine Programm | + | Ein Soundserver ist eine Programm das 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 | + | Soundserver werden benötigt wenn wenn das unterliegende Audio-Ausgabegerät nur einen 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 | + | 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 === | === 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 liefern das auch für den Heim-Anwender angemessen ist. | 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. | ||
Zeile 36: | Zeile 32: | ||
==== Im Studio Betrieb ==== | ==== Im Studio Betrieb ==== | ||
− | Wie oben schon angedeutet ist RoarAudio aber im Studio | + | 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: | Ein analoges Mischen hat hier nun mehre Nachteile, die wichtigsten sind wohl: | ||
Zeile 48: | Zeile 44: | ||
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. | ||
− | |||
− | |||
=== Exkurs: Codecs und Container === | === Exkurs: Codecs und Container === | ||
Zeile 62: | Zeile 56: | ||
* Sprach Codecs | * Sprach Codecs | ||
* Niederlatenz Codecs | * Niederlatenz Codecs | ||
− | + | ||
=== Was hebt RoarAudio hervor? === | === Was hebt RoarAudio hervor? === | ||
Zeile 70: | Zeile 64: | ||
RoarAudio zeichnet sich dadurch aus daß er zusätzlich zu PCM Rohdaten auch höher Codecs versteht. Dies hat mehre Vorteile: | 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 | + | * Der Server kann Streams in höheren Codecs selbstständig verarbeiten. Dies ist zum Beispiel wichtig um Webradio als Background Stream ab zu spielen. |
* 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 | + | * 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 ==== | ||
− | RoarAudio ist | + | 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: | + | 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 ==== | ||
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. | 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. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Virtual IO ==== | ==== Virtual IO ==== | ||
Zeile 97: | Zeile 86: | ||
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''' | + | 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. | 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. | ||
Zeile 130: | Zeile 119: | ||
=== Konzepte und Architektur === | === Konzepte und Architektur === | ||
− | RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert | + | RoarAudio ist zwar in C geschrieben aber größtenteils Objekt-orientiert. |
==== Clients und Streams ==== | ==== Clients und Streams ==== | ||
Zeile 137: | Zeile 126: | ||
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 | + | 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 läßt. 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. | + | 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. Hier durch ist eine maximale Flexibilität gegeben. |
===== Stream Typen ===== | ===== Stream Typen ===== | ||
− | Es gibt diverse | + | Es gibt diverse Verschiedene Stream typen. Die folgende Tabelle Beschreibt sie kurz: |
{| class="wikitable" | {| class="wikitable" | ||
Zeile 159: | Zeile 148: | ||
| Filter | | Filter | ||
| bidirektional | | bidirektional | ||
− | | Dieser Stream dient zum | + | | Dieser Stream dient zum zwischenschalten von Filtern im Mixer |
|- | |- | ||
| Output | | Output | ||
Zeile 173: | Zeile 162: | ||
| Play und Monitor in einem. | | Play und Monitor in einem. | ||
|- | |- | ||
− | |||
| Record | | Record | ||
| vom Server | | vom Server | ||
Zeile 186: | Zeile 174: | ||
| Im Moment nicht Unterstützt. | | Im Moment nicht Unterstützt. | ||
|- | |- | ||
− | |||
|} | |} | ||
Zeile 229: | Zeile 216: | ||
=== Probleme des Realtime Audio Mischens === | === Probleme des Realtime Audio Mischens === | ||
− | Beim Mischen in Realtime kommen zu den Problemen | + | Beim Mischen in Realtime kommen zu den Problemen die beim normalen Mischen von Audio auftreten noch weitere hinzu. |
Die wichtigsten Probleme sind: | Die wichtigsten Probleme sind: | ||
− | * Resampling - Wenn nicht alle Streams dieselbe | + | * Resampling - Wenn nicht alle Streams dieselbe Abtastfrequens 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 vor allem schnell sein, will aber auch noch möglichst gut sein. Viele Soundserver behalten schlichtweg die Pegel entsprechend der neuen Abtaste Rate länger oder kürzer bei. 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. | + | * 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 dem 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 | + | * 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 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. |
− | * | + | * 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-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. |
Zeile 243: | Zeile 230: | ||
Die wichtigsten Störfaktoren sind: | 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 | + | * 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 ab zu fragen 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 | + | * Neben dem Delay in der Hardware erzeugt selbstverständlich auch der Kernel und die Treiber eine weiter Verzögerung. Dies passiert aus vielen Gründen: Der Programmcode muss natürlich erst einmal ausgeführt werden. Auch werden Interupts nicht um bedingt 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 | + | * Die nächste Schicht, die Sound APIs, erzeugen auf ähnliche Weise weitere Delays. Hier kommt dazu das viele mit relativ großen Puffern arbeiten. 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. | * 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 | * Unsynchrones clocking | ||
Zeile 253: | Zeile 240: | ||
* jitter | * jitter | ||
* Netzwerk Implementierungen | * Netzwerk Implementierungen | ||
− | + | * QoS | |
− | |||
− | |||
− | |||
− | * | ||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Sonstiges === | === Sonstiges === | ||
... | ... | ||
==== Win32 Port ==== | ==== Win32 Port ==== | ||
− | Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32 | + | Ein Win32 Port existiert zum jetzigen Zeitpunkt nicht. Dies liegt an mehren Faktoren: Zum einen ist Win32 nicht 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 Filehandle seinen eigenen Satz Funtionen. RoarAudio verfolgt die UNIX Philosophie: ''Alles ist eine Datei''. Große Patches wären nötig. |
Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt. | Ein Weiteres ist das ein solcher Port viel Zeit in Anspruch nimmt und weder das Projekt noch die Freie Software Bewegung voranbringt. | ||
Zeile 278: | Zeile 256: | ||
==== MP3 ==== | ==== MP3 ==== | ||
− | + | ... | |
− | |||
− | |||
− | |||
=== Querverweise === | === Querverweise === | ||
Zeile 294: | Zeile 269: | ||
=== Vorführung === | === Vorführung === | ||
− | |||
− | |||
* Allgemeiner Betrieb | * Allgemeiner Betrieb | ||
** roard | ** roard | ||
** roarvorbis/roarcatplay? | ** roarvorbis/roarcatplay? | ||
− | |||
** xmms | ** xmms | ||
* Background Streams | * Background Streams | ||
Zeile 305: | Zeile 277: | ||
* Kompatibilitäts Bibliotheken | * Kompatibilitäts Bibliotheken | ||
** libroaresd: | ** libroaresd: | ||
− | *** | + | *** xmms |
− | *** | + | *** mplayer |
*** Amarok | *** Amarok | ||
Zeile 312: | Zeile 284: | ||
* ''immer gerne'' | * ''immer gerne'' | ||
− | |||
[[Kategorie:Vortrag]] | [[Kategorie:Vortrag]] | ||
[[Kategorie:Software]] | [[Kategorie:Software]] | ||
[[Kategorie:Sound]] | [[Kategorie:Sound]] |