PulseAudio

PulseAudio
PulseAudio Device Chooser (padevchooser)
Basisdaten
Maintainer	Lennart Poettering, Pierre Ossman, Shahms E. King, u. a.
Entwickler	Lennart Poettering
Aktuelle Version	1.1 (20. Oktober 2011)
Betriebssystem	Unix (GNU/Linux, BSD, Solaris), Windows
Programmier­sprache	C[1]
Kategorie	Middleware, Soundserver
Lizenz	LGPL 2.1 (Freie Software)[2]
pulseaudio.org

PulseAudio (früher auch PolypAudio genannt, s. u.) ist eine netzwerktransparente, plattformunabhängige Sound-Middleware, deren API sich an Konzepten des davon abgelösten Enlightened Sound Daemon (ESD) anlehnt.

Die Client-Bibliotheken sind auf jeder netzwerkfähigen Plattform nutzbar (z. B. auch embedded oder mobile Geräte), der PulseAudio Daemon als zentraler Soundserver und Hardware-Schnittstelle sowie die dazugehörigen Hilfsprogramme sind auf allen POSIX-kompatiblen Systemen und Microsoft Windows verfügbar.

PulseAudio ist freie Software, gemäß den Bestimmungen der GNU Lesser General Public License.^[2]

Funktionsweise

PulseAudio basiert auf zwei grundlegenden Prinzipien:

• Alle Audioströme werden durch den PulseAudio Daemon (Soundserver) geleitet.
• Ausschließlich der PulseAudio Daemon selbst greift auf die physische Soundhardware des Systems zu, auf dem er läuft.

Daraus ergeben sich sowohl Vor- als auch Nachteile:

Vorteile

Ein zentrales Anliegen von PulseAudio ist es, einerseits die Anwendungen weitestgehend von der tatsächlichen Soundhardware zu trennen (Abstrahierung), ihnen aber andererseits mehr Einfluss auf das Verhalten der Audioströme zu geben, ohne die Komplexität übermäßig zu vergrößern (durch Metadaten).
Erreicht wird dies durch die oben genannten Prinzipien, aufgrund welcher alle Prozesse gezwungen sind, ihre Sounddaten an PulseAudio zu übergeben. Dadurch entfällt die Verantwortung der einzelnen Programme für die Sounddaten und wird an zentraler Stelle, nämlich dem PulseAudio Daemon, gebündelt. Dessen Schnittstelle ermöglicht, Einfluss auf die Audiodaten zu nehmen, ohne dass die einzelnen Prozesse in irgendeiner Form darin involviert sind.

Nachteile

Erste und offensichtlichste Folge ist, dass ausschließlich Programme, die die PulseAudio-Client-Bibliotheken verwenden, in der Lage sind, Soundein- oder Ausgabeströme zu benutzen. Solange keine Legacy-Anwendungen zum Einsatz kommen, ist dies nicht relevant (fast alle aktuellen Audio- und Mediaplayer sowie die meisten portablen Audio-Bibliotheken (z.B. OpenAL oder SDL) unterstützen PulseAudio direkt).

Schema der Audioströme durch PulseAudio

Damit sich PulseAudio jedoch auch bei Verwendung älterer Programme möglichst nahtlos ins System einfügt, wurden zusammen mit dem eigentlichen Soundserver eine Reihe spezialisierter Anwendungen entwickelt. Diese Adapter genannten Programme sind einerseits normale PulseAudio-Clients, andererseits bieten sie aber Prozessen auch den Zugriff über andere, auch normalerweise exklusive, Audio-Schnittstellen an, wobei die Daten dann transparent via PulseAudio weiterverarbeitet werden, ohne dass seitens der Legacy-Programme Änderungen nötig sind. Aufgrund der Vielzahl dieser Adapter entstand der ursprüngliche Name PolypAudio.

Ein Beispiel ist die Verwendung unter GNU/Linux, wo als Hardware-Soundschnittstelle normalerweise ALSA zum Einsatz kommt: Während ALSA zwar auch selbst standardmäßig einen simplen Mischer in Form des DMix-Plugins mitbringt und so theoretisch der PulseAudio Daemon parallel zu reinen ALSA-Anwendungen betrieben werden kann, wird für gewöhnlich ein anderer Weg beschritten: Statt des Dmix-Plugins wird der ALSA-PulseAudio-Adapter geladen, der die PulseAudio-Kanäle als ALSA-Soundgeräte den Anwendungen zur Verfügung stellt. Die physischen ALSA-Geräte werden vom PulseAudio Daemon im exklusiven Zugriff gesperrt und der PulseAudio-Adapter als Standard-Audio-Gerät für ALSA definiert. Damit nutzen alle Programme, die ALSA verwenden, automatisch PulseAudio. Ob der Daemon selbst die ALSA-Hardware zur Soundausgabe nutzt oder nicht, spielt keine Rolle.
Damit ist es möglich, selbst auf einem System, das über keinerlei physische Soundhardware verfügt und die Audioausgabe z.B. über einen per WLAN verbundenen Verstärker erledigt, normale ALSA-Software ohne Änderungen zu verwenden.
Einschränkungen gibt es, wenn Programme bestimmt Hardwareeigenschaften oder -verhalten erwarten, die vom Adapter nicht emuliert werden können (z.B. festes RAM-Locking oder eine bestimmte Geräte-Nummerierung), sowie bei gemischten 32/64bit Systemen, wenn nicht alle Bibliotheken in beiden Versionen vorliegen.

Die Schnittstelle zum älteren Open Sound System kann durch ALSA emuliert werden (aoss), PulseAudio stellt jedoch auch einen eigenen Adapter (padsp) bereit, der die OSS-Gerätedateien (z.B. /dev/dsp) selbst erstellt und verwaltet.

Programme, die statt PulseAudio noch den Enlightened Sound Daemon (ESD) erwarten, werden direkt unterstützt, da PulseAudio als vollständiger Ersatz für ESD fungiert und dessen Schnittstellen mit übernommen hat.

Geräteunabhängigkeit

Die einzelnen Audioströme sind nicht an eine bestimmte Hardware gebunden und können, ohne dass die damit verbundenen Prozesse davon beeinflusst werden, im laufenden Betrieb auf andere Geräte umgeleitet werden. Dies kann sowohl manuell über die von den PulseAudio-Hilsprogrammen bereitgestellte grafische Oberfläche erfolgen, als auch automatisch. Dafür stellt PulseAudio eine skriptfähige Schnittstelle zur Verfügung, die z. B. beim Anschließen oder Entfernen eines Soundgerätes verwendet wird. Durch benutzerdefinierbare Präferenzen kann so bestimmte Soundhardware (wenn sie verfügbar ist) gegenüber anderer bevorzugt werden.
Ein Beispiel ist die Verwendung eines Notebooks, das beim Verbinden mit der Dock-Station die Soundausgabe automatisch von den integrierten Lautsprechern auf den WLAN-Verstärker und die Soundeingabe auf das feste Mikrofon umschaltet, ohne dass es dabei zu einer Unterbrechung der Audioströme kommt. Beim Entfernen vom Dock tritt der umgekehrte Effekt ein.
Präferenzen können mehrstufig sein, z. B. kann ein Bluetooth- oder USB-Headset wiederum eine noch höhere Priorität haben und so zeitweise sowohl die eingebaute als auch die Soundhardware des Docks verdrängen, unabhängig davon ob es zuhause oder unterwegs angeschlossen wird.
Neben den Audiodaten können PulseAudio-Clients auch zusätzliche Metadaten an den Soundserver schicken, die bei der Auswahl des Zielgerätes berücksichtigt werden. So können z. B. die Sounds von Systemmeldungen immer über die eingebauten Lautsprecher, Musik und die Audiospur von Videos über das jeweils bevorzugte Gerät, VoIP-Telefonate aber nur über das Headset geleitet werden.
Neben dem Wechsel von Geräten können auch virtuelle Geräte, z. B. als Zusammenfassung mehrerer physischer oder logischer Soundgeräte definiert werden, die von den Clients normal benutzt werden können. Für ein Screencast lässt sich so z. B. die komplette Ausgabe der PulseAudio-Soundpipeline plus der Eingabe des Mikrofons als neues Eingabegerät (entweder gemischt oder als zusätzliche Spur) schaffen, von dem problemlos einzeln aufgenommen werden kann, ohne späteres Mischen oder Nachbearbeiten zu erfordern. Damit verbunden, lassen sich mehrere Kanäle synchronisieren, ohne dass die Clients selbst die notwendige Wartelogik implementieren müssen.

Ein relativ grundsätzliches Problem bei der Audioausgabe unter Linux ist, dass es keine klare Schichtung gibt, sondern verschiedene Systemedienste, bzw. Subsysteme, die den Zugriff auf die Audiohardware, Anpassungen der Abtastrate, Mischen gleichzeitiger Audioströme, Sitzungsmanagement, Zugriffskontrolle, sowie fortgeschrittene Signalverarbeitung in überlappender Weise implementieren. PulseAudio verfolgt dabei den Ansatz, einen vergleichsweise großen Umfang von Diensten in einem Teilsystem zu vereinigen.

Kopplung an die Benutzersitzung

Der PulseAudio-Server ist nicht als systemweiter Server konzipiert, der unabhängig von einer Benutzersitzung läuft, vielmehr ist die Hardware ähnlich wie Maus und Bildschirm beim X-Windows Display der Benutzersitzung zugeordnet. Für die meisten Desktop-Applikationen ist dies wünschenswert, da ein Zugriff auf die Audio-Eingänge es prinzipiell auch ermöglicht, ein System über das Internet abzuhören, was ein erhebliches Sicherheitsrisiko darstellen kann. Eine Konfiguration im soganannten "System Mode" ist prinzipiell möglich, jedoch wird hiervon - sowohl aus Gründen der Sicherheit als auch aufgrund gravierender technischer Nachteile - ausdrücklich abgeraten^[3]. Dies steht im Konflikt zu Konzepten, bei denen ein Medienserver wie etwa Music Player Daemon normalerweise als Systemdienst für einen direkten Zugriff auf die Audio-Hardware konzipiert ist, ohne dass notwendigerweise die vollständigen Audio-Daten übertragen werden. Es ist jedoch möglich, auf PulseAudio-Dienste systemweit über die Netzwerk-Schnittstelle zuzugreifen, wobei sich allerdings für die Zugriffsregelung noch kein durchgängiges und einheitliches Konzept etabliert hat, wie es im Bereich der Texteingabe beispielsweise mit den Pseudoterminals besteht.

Netzwerkfähigkeit

Durch die Abstraktion können PulseAudio-Clients entfernte und lokale Soundhardware gleichermaßen benutzen, ohne dass dies zusätzlichen Programmieraufwand erfordert. Möglich ist sowohl, dass der lokale PulseAudio Daemon die Daten einem anderen, per Netzwerk erreichbaren Daemon überlässt, als auch, dass der Client direkt einen anderen PulseAudio Server im Netz kontaktiert. Da ein PulseAudio Daemon eine Möglichkeit ist, per Netzwerk auf physische Soundhardware zuzugreifen, muss auf Systemen ohne Soundhardware kein Soundserver laufen. Somit kann in einem Netz mit zentralen Audiogeräten, z. B. einem Heimkino oder in einem Studio, von allen Systemen aus der gleiche, zentrale Soundserver benutzt werden (jedoch s.u. bzgl. Zugriff und Sicherheit).

Soundfilter

Alle Audiodaten passieren zwangsweise den PulseAudio Daemon, der damit auch ein geeigneter Ort für die Anwendung von Soundfiltern ist, zumal die meisten heutigen Prozessoren in der Lage sind, gleichartige Berechnungen parallel auf mehreren Datensätzen durchzuführen.
Wichtigster und auch in den grafischen Benutzeroberflächen essentiellster Punkt ist die Möglichkeit, die Lautstärke jedes Audiokanals und jedes Audiostroms jeder Anwendung einzeln zu konfigurieren (oder stummzuschalten), auch wenn das entsprechende Programm dafür keine eigene Möglichkeit bietet.^[4] Diese Einstellungen können gespeichert werden und bleiben dann für die jeweilige Anwendung bestehen. Daneben können auch Equalizer-Funktionen genutzt werden.
Nicht jede Soundhardware kann die gleichen oder überhaupt unterschiedliche Samplingfrequenzen verarbeiten. Manche Anwendungen erzeugen Audioströme mit festen Abtastraten und erwarten auch solche als Eingabe. Der PulseAudio Daemon nimmt die notwendige Konvertierung automatisch vor und stellt dafür unterschiedlich CPU-intensive Algorithmen zur Verfügung. Damit verbunden ist ein vielfach auftretendes Problem, dass ein qualitativ besserer aber auch rechenintensiverer Algorithmus voreingestellt ist (resample-method in /etc/pulse/daemon.conf).

Eigenschaften

An physischer Soundhardware unterstützt PulseAudio alles, was das jeweils native Soundsystem des Betriebssystemes unterstützt. Unter GNU/Linux ist dies ALSA, OSS unter BSD und DirectSound unter Microsoft Windows. Jedes Soundgerät ist entweder Quelle (Source) oder Ziel (Senke) für Audiodaten. Daneben kommen andere, über das Netzwerk verbundene PulseAudio Server sowie Geräte oder Prozesse, die das RTS-Protokoll unterstützen in Frage. Auch PulseAudio-Clients selbst können sowohl Senke als auch Quelle sein. Viele Adapter unterstützen jedoch oft nur die Funktion als Quelle für den adaptierten Prozess. PulseAudio kann auf Bluetooth-Audiogeräte zugreifen, auch wenn das native Soundsystem diese nicht unterstützt (solange Bluetooth allgemein unterstützt wird).

Der PulseAudio Daemon bietet die Möglichkeit, während der Laufzeit durch ladbare, binäre Module erweitert zu werden. Die meisten Adapter und Filter sind auf diese Weise implementiert.

Die Latenz der meisten Operationen ist sehr niedrig^[5] und kann von den Clients gemessen und beeinflusst werden. Eine hohe Latenz kann auf embedded und mobilen Geräten zu Energieeinsparungen führen, eine geringe Latenz ist z.B. für VoIP oder Multiplayer-Spiele erforderlich.

Innerhalb des Daemons sowie der lokalen Clients kommt die PulseAudio-Soundarchitektur ohne das zeitaufwändige Umkopieren von Audiodaten aus (zero-copy architecture), dies gilt jedoch nur begrenzt bei der Verwendung von Adaptern.

Aufgrund der Abhängigkeit vom Zugang zum PulseAudio Daemon für alle Audiofunktionen ist dieser in der PulseAudio-Client-Bibliothek zentral und automatisch geregelt, welche neben dem reinen Auffinden eines Servers die Möglichkeit der bevorzugten Auswahl aus mehreren verfügbaren bietet. Sofern nicht abgeschaltet, ist ein Server mittels Zeroconf im Netz automatisch auffindbar. Lokal kann dies via DBus erfolgen. Adapter, insbesondere der ALSA-Adapter, und auch PulseAudio-Clients können jedoch auch selbst den PulseAudio Daemon starten, wenn dieser so konfiguriert ist und lokal noch nicht läuft. X11-Desktopumgebungen erledigen dies normalerweise automatisch.

Auf unterster Ebene sind für den Zugang zum Server zwei Umgebungsvariablen notwendig: PULSE_SERVER und PULSE_COOKIE. Diese werden von der PulseAudio-Client-Bibliothek ausgewertet oder, wenn sie noch nicht existieren, gesetzt. Standardmäßig ist der Daemon X11-sessionbasiert konfiguriert, d.h. die Variablen sind nicht gesetzt, die Einstellungen werden jedoch beim Start des Daemons in die Ressourcen des Root X-Window eingetragen und von den Clients dort ausgelesen und können so z.B. auch über eine ssh-getunnelte Verbindung "mitgenommen" werden. Ohne die X11-Sitzungsverwaltung können die Zugangsdaten via DBus erfragt werden.

Für die Zugriffskontrolle auf den Server übernimmt PulseAudio die Methode von X11 und verwendet dafür ein pseudozufällig generiertes "Cookie", das in PULSE_COOKIE erwartet wird, und standardmäßig aus der Datei ~/.pulse-cookie des Benutzers stammt, unter dessen Konto der Daemon läuft. Normalerweise ist PulseAudio so konfiguriert, dass ohne dieses Cookies ein Zugriff auf den Server, auch lokal, nicht möglich ist, selbst wenn der Prozess dem gleichen Benutzer gehört wie der Daemon.

Ein häufiges Problem ist daher das Fehlen einer oder beider Variablen, besonders bei der Verwendung von Adaptern, die den Daemon selbst starten. Eine einfache, wenn auch sehr unsichere, Variante ist daher das zentrale Eintragen der Variablen in /etc/profile, womit alle lokalen Benutzer automatisch den gleichen PulseAudio Daemon nutzen. Die aktuellen Werte können mit xprop -root|grep PULSE aus dem Root-Window ausgelesen werden. Dies funktioniert auch im Netz, ist jedoch wegen der oben erwähnten Fähigkeit des Daemons zum Nachladen binärer Module nur begrenzt empfehlenswert.

Weblinks

• Projekthauptseite (englisch)

Einzelnachweise

1. ↑ Ohloh Analysis Summary - PulseAudio. Ohloh. Abgerufen am 14. Mai 2010.
2. ↑ ^{a b} LICENSE. Pulseaudio git. Abgerufen am 2010. Mai 14.
3. ↑ What is Wrong with system mode?
4. ↑ Interviews/LennartPoettering. In: Fedora Project Wiki. 2. November 2007, abgerufen am 5. Februar 2008 (englisch). 
5. ↑ JD Mars: Better Latent Than Never. Abgerufen am 5. Februar 2008 (englisch).