rss feed articles activities all_comments

indeedgeek.de

Florian Eitel

Sound unter Linux

Wenn der Klang Achterbahn durch die Soundsysteme fährt

Oftmals ist man schon wirklich froh wenn man überhaupt etwas hört. Sound unter Linux ist wirklich ein leidiges Thema und doch lässt sich mit etwas Hingabe ein wirklich hervorragendes Setup erstellen, von dem man unter Mac nur träumen kann. Das Problem ist unter Linux das übliche: Zu viel Auswahl und zu viele Kombinationsmöglichkeiten die in den verschiedenen Abstaktionslayern völlig unter gehen. Daher dachte ich mir, ich stelle die unterschiedlichen Architekturen, die man unter Linux findet kurz vor.

OSS – Open Sound System

Am Anfang war OSS. OSS war das erste System welches im Kernel eine einheitliche Abstraktion der Soundkarte bereit stellt. Sie stellte ein Device unter /dev/dsp bereit. Alles was da rein geschrieben wird, hört man als Klang. Alles was daraus gelesen wurde kam vom Mikrophon. Für jede Soundkarte musste ein eigener OSS Treiber geschrieben werden damit der Kernel weiß was er mit den Klangdaten machen soll. Für die Applikationen war die Nutzung denkbar einfach. Allerdings hatte OSS einige schwerwiegende Designprobleme: Zum einen konnte man nur eine Soundkarte nutzen und nur eine Applikation konnte gleichzeitig Sound abspielen. OSS ist in aktuellen Kernel (2.6) als deprecated markiert. Auch wenn es eine recht neue Implementierung namens OSS4 gibt spielt OSS keine große Rolle mehr. Sollte es keinen neuen Treiber geben macht OSS unter Umständen Sinn. Zudem hat OSS4 einige wenige Funktionen die ALSA (dazu gleich mehr) nicht hat wie das Regeln der Lautstärke für einzelne Quellen.

esd/EsounD – Enlightened Sound Daemon

esd war der Vorstoß von Gnome die Probleme mit OSS<4 zu lösen. Es handelt sich dabei um einen Aufsatz auf OSS (später auch Alsa) der einzelne Applikationen verwaltet. Die Programme senden ihren Sound an esd, der das dann abmischt und an OSS weiter leitet. esd hatte noch die Vorteile wie das Regeln der Lautstärke für einzelne Quellen oder Netzwerktransparenz. Allerdings spielt heute esd keine Rolle mehr, außer bei alter Software die nur mit esd laufen.

aRts – analog Real time synthesizer

aRts war der Gegenpol zu esd aus der KDE2/3 Welt. Es löst die selben Probleme wie esd nur legt gesondert wert auf Realtime Fähigkeit. Somit entstehen keine Verzögerungen bei der Ausgabe von Musik oder dem Aufnehmen von Sound. aRts wird nicht mehr verwendet.

ALSA – Advanced Linux Sound Architecture

Nach langem hat ALSA offiziell OSS3 abgelöst und somit esd/aRts unnütz gemacht. ALSA mixed verschiedene Quellen und benötigt so kein extra Aufsatz. Dabei kann aber die Lautstärke nicht einzeln geregelt, sondern nur der globale Mixer der Soundkarte verstellt werden. Zu Alsa gehört einmal ein Kernelmodul welches die API bereit stellt. Dazu gibt es verschiedene Treiber für die Soundkarten als Backend. Diese sind nicht mit den Treibern von OSS kompatibel und so musste man viele umschreiben. Auch Applikationen müssen extra für ALSA geschrieben werden allerdings bietet ALSA ein OSS Interface für Software die nur mit OSS umgehen kann. Super ist, dass ALSA im Userspace schon mit Streams rudimentär umgehen kann. So ist es zum Beispiel möglich über das dmix Plugin gewisse Quellen auf einen globalen Equalizer umzuleiten. Zudem unterstützt ALSA mehrere Soundkarten. ALSA ist aktuell definitiv die Wahl wenn es um Sound geht. Zwar fehlen einige Einstellungsmöglichkeiten, aber ALSA bietet einen ähnlichen Umfang den man auch von anderen Systemen gewohnt ist: Mehrere Applikationen, eine Lautstärke für alle Applikationen, systemweiter Equalizer, bis zu acht Soundkarten.

xine

Die ganze Vielfalt die eine geraume Zeit herrschte machte es für die Anwendungsentwickler schwierig für alle Konfigurationen eine passende Unterstützung einzubauen. Zudem kam die Zeit in der Multimedia eine größere Rolle spielte. Man wollte Filme und Sound in verschiedensten Formaten und Quellen abspielen. Daher hat sich xine vor allem in der QT Welt sehr verbreitet gewesen. Man konnte damit recht komfortabel Videos und Sound in verschiedensten Formaten und beliebigen Backends wiedergeben. Heute findet sich xine eher selten da andere Frameworks haben xine abgelöst.

gstreamer

GStreamer hat sich als Gegenpol in der GTK Welt zu xine entwickelt. Da GStreamer eine sauberere Architektur hat und mehr Funktionalitäten besitzt, hat es xine aber auch auf QT Systemen überholt. GStreamer erlaubt es Video und Audio aufzuzeichnen, abzuspielen, streamen oder zu bearbeiten. Diese einzelnen Elemente werden durch Plugins realisiert. So ist es zum Beispiel möglich über HTTP ein MP3 zu streamen, dieses in ogg zu transformieren und als Datei abzuspeichern. Dabei sind für HTTP/FILE/MP3/OGG verschiedene Plugins beteiligt die ineinander gesteckt werden. Dabei werden die Plugins in Good, Ugly und Bad unterteilt je nach Probleme die man damit bekommen wird (Lizenz, Qualität, …). GStreamer ist Standard auf so ziemlich allen Systemen.

Phonon

Während GTK Programme in der Regel direkt mit GStreamer sprechen (oder direkt ALSA, oder …) ist es in der KDE Welt üblich dies seit KDE4 über Phonon zu verwalten. Phonon abstrahiert noch einmal xine/gstreamer und einige der Nachfolgenden Lösungen. Dazu kann ich nicht sonderlich viel sagen. Anscheinend lässt sich die Hardware steuern und das Routing der einzelnen Streams durch das Sound-System. Backend switchen on the fly hört sich ganz nett an aber ich habs noch nicht gebraucht…

Pulseaudio

Nun zu meinen beiden Lieblingen. Für Viele hört es bei ALSA auf. GStreamer eventuell noch aber dann ist auch gut. Schade, weil jetzt fangen erst die wirklichen Features =) an.

Zu erst einmal Pulseaudio: Pulseaudio setzt wiederum auf verschiedenen Backends auf. Meist wird wohl ALSA verwendet aber auch oss, bluetooth oder Jack welches ich nachfolgend erwähne. Die Programme müssen speziell für Pulseaudio entwickelt werden. Sie registrieren sich beim pulseaudio Server und senden den Klang dort hin. Dieser kann für jeden Stream die Lautstärke und das Ziel anpassen. Zum Beispiel ist es möglich die Musik als Stream aufs Netzwerk auszugeben und den lokalen Telefonanruf auf die Kopfhörer. Und sobald der Anruf vorbei ist wieder die Musik auch auf die Kopfhörer.

Zudem bietet pulseaudio verschiedene Plugins wie DBus, Bluetooth, dem schon erwähnten RTP Stream, RTP Empfang oder HTTP Streaming. So kann man sein Setup schon zusammen stecken. Etwas schade ist, dass man primär nur die Sink bzw Source für einen Stream einstellen kann. Schöner wäre wenn man da auch noch Equalizer dazwischen klemmen könnte oder ähnliches. Das geht bereits rudimentär, aber ein verbessertes Routing ist in Arbeit.

Pulseaudio findet man in fast allen Distributionen mittlerweile als Standard. Ich nutze es auch seit einiger Zeit und bin sehr zufrieden. Wenn mal Flash zu laut ist wird es runter gedreht oder auf eine null-sink gelegt und so komplett ausgeblendet. Super! Problematisch ist nur, dass noch nicht alle Programme Pulseaudio unterstützen. Deswegen gibt es ein ALSA Plugin welches das nach Pulseaudio einschleift. Somit spricht die Applikation mit ALSA, das wird an Pulseaudio übergeben und das gibt es dann wieder auf ALSA aus um es auf der Soundkarte auszugeben. Auch für alte Techniken wie OSS oder esd gibt es entsprechende Plugins. Zudem hat Pulseaudio sicherlich das schönste Frontend zur Konfiguration.

jack – JACK Audio Connection Kit

Jack ist definitiv für den advanced Gebrauch. Ich finde Jack ist eher so etwas, was dann hochgefahren wird wenn man schwere Geschütze braucht und danach wieder abschaltet. Das besondere an Jack ist wohl die Realtime-Fähigkeit. Gerade für Tonstudios mag es interessant sein ein Signal aufzuzeichnen, das über den Equalizer zu jagen und dann sofort als Monitor-Signal auszugeben. Da darf es zu keiner Verzögerung kommen. Das unterstützt Jack (angeblich – nicht getestet ^^). Jack setzt auf ALSA/OSS auf und fungiert wie Pulseaudio auch als Zwischenschicht. Die Programme müssen auch Jack explizit unterstützen wobei es auch hier wieder Adapter gibt. Vor allem interessant ist der Pulseaudio Adapter mit dem man das abgemischte Pulseaudio-Signal in Jack einschleifen kann.

Wirklich super ist die Routing-Möglichkeit in Jack. Jedes Programm welches Jack nutzt meldet sich als Device an und hat verschiedene Ports für Ein/Ausgabe. Möchte man zum Beispiel den Pegel der Soundkarte anzeigen so kann man über Verbindungslinien im Konfigurationsdialog den Ausgang vom Mikrofon mit dem Volume-Meter Eingang verbinden und dessen Ausgang mit dem aufzeichnen Programm. Super wird es aber erst mit richtigen Tonstudio Programmen wie Ardour bei denen jede Spur auch in Jack auftaucht und dort mit einer anderen verbunden werden kann. Und das einfach über GUI – macht echt Spaß. Ein einfaches Szenario wäre das aufzeichnen eines Signals wobei man dabei Musik hören möchte die selbstverständlich nicht aufgezeichnet werden soll. Einfach Player mit Aufnahme und Musik mit Soundkarte verbinden und schon sind die beiden Streams unabhängig.

Zu beachten ist, dass es einmal Jack und Jack2 gibt. Jack2 ist eine Neuimplementierung in C++ und wird sehr schnell weiter entwickelt. Verbreitet ist allerdings primär Jack. Jack2 ist besser für mehrere Prozessoren ausgelegt und unterstützt DBus. Jack2 habe ich selbst noch nicht probiert aber vor allem die Integration von Pulseaudio soll wegen dem DBus Interface automatisch laufen. Irgendwann mal probieren…

Der Rest

Neben all diesen Möglichkeiten bringen VLC oder mplayer wiederum eigene Codecs und Abspielmöglichkeiten mit sich. So ist es beispielsweise möglich in Phonon das VLC Framework als Backend auszuwählen. Welche Vorteile man davon im Gegenzug zu zum Beispiel Gstreamer hat, kann ich aber nicht erkennen.

Nochmal langsam

Das war etwas viel. Man kann so ziemlich alles an alles anstecken wobei nur weniges davon Sinn macht.

Was macht nun Sinn?

Zum ersten muss man schauen was die Applikationen unterstützen. Bei Altlasten die OSS/aRts/esd/xine verwenden lieber die Finger von lassen – macht nur Probleme. Die Basis ist sicher einmal ALSA. Wenn das läuft, und man keine weiteren Ansprüche hat, ist man schon fertig. Schön ist auch gstreamer wobei man sich als Anwender darum eher nicht kümmern muss. Bei KDE wird man um Phonon nicht vorbei kommen aber auch hier macht die zusätzliche Abstraktionsschicht kaum einen Unterschied. Ich finde Pulseaudio ist definitiv ein Blick wert. Auch wenn die Applikationen das noch etwas besser unterstützten könnten. Zumindest Gstreamer und Phonon integrieren sich gut. Für den professionellen Einsatz lohnt es sich Jack zu starten. Um sein bestehendes Setup beizubehalten sollte man dann Pulseaudio über Jack laufen lassen. Dazu muss Pulseaudio kurz angehalten werden (damit er die ALSA Soundkarte frei gibt), Jack gestartet, und Pulseaudio auf Jack umgeleitet werden.

So ich hoffe nun ihr blickt nun durch. Etwas konfus da noch viele Altlasten entstehen und alles zu allem kompatibel ist. Aber bevor ihr das nächste Mal flucht weil kein Sound kommt, hilft euch dies ja eventuell beim Verstehen.

Comments:

(howto comment?)