PulseAudio
| PulseAudio
| |
|---|---|
| PulseAudio-Piktogramm | |
 PulseAudio Device Chooser (padevchooser) | |
| Basisdaten
| |
| Maintainer | Lennart Poettering, Pierre Ossman, Shahms E. King, u. a. |
| Entwickler | Lennart Poettering |
| Betriebssystem | Unix (GNU/Linux, BSD, Solaris), Windows |
| Programmiersprache | 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 Konzepte des davon abgelösten Enlightened Sound Daemon (ESD) anlehnt.
Die Client-Bibliotheken sind auf jeder netzwerkfähigen Plattform nutzbar (z. B. auch eingebettete 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 mit einer veralteten Version auf 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 Hardware-Soundschnittstelle (Software-Abstraktion der physischen Soundhardware) des Systems zu, auf dem er läuft.
Die meisten Programme können direkt mit PulseAudio kommunizieren:
- Soundquelle → PulseAudio → ALSA-Treiber → Hardware
Wenige Programme können nicht mit PulseAudio kommunizieren:
- Soundquelle → ALSA → PulseAudio → ALSA-Treiber → Hardware
PulseAudio ist auch netzwerkfähig:
- Soundquelle → PulseAudio → Netzwerk → PulseAudio → ALSA-Treiber → Hardware
Ohne PulseAudio kann das Programm direkt mit dem Soundkarten-Treiber (hier: ein ALSA-Treiber) kommunizieren:
- Soundquelle → ALSA-Treiber → Hardware
Alternativ sollten Programme mit dem ALSA-Soundserver kommunizieren:
- Soundquelle → ALSA → ALSA-Treiber → Hardware
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).
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 Linux, wo als Hardware-Soundschnittstelle normalerweise ALSA zum Einsatz kommt: Während einige wenige Linux-Treiber für Soundkarten Mixing in Hardware durchaus unterstützen, und außerdem ALSA auch selbst standardmäßig einen simplen Software-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 Audioverstärker erledigt, normale ALSA-Software ohne Änderungen zu verwenden.
Einschränkungen gibt es, wenn Programme bestimmte 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 (OSS) 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-Hilfsprogrammen 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 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-Window 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 sogenannten „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 Betriebssystems unterstützt. Unter GNU/Linux ist dies ALSA, OSS unter BSD und DirectSound unter Microsoft Windows. Jedes Soundgerät ist entweder Quelle (Source) oder Senke (Sink) 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 D-Bus 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 D-Bus 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 Cookie ein Zugriff auf den Server, auch lokal, nicht möglich ist, selbst wenn der Prozess dem gleichen Benutzer gehört wie der Daemon.
Alternativen
In professionellen Anwendungen unter Linux wird gerne Jack als ebenfalls freie Alternative oder Ergänzung zu PulseAudio verwendet.
PipeWire, welches bspw. ab Fedora 34 PulseAudio und Jack ersetzt.[6]
Teile der Funktionalität von PulseAudio können mit spezielleren und teilweise proprietären Lösungen, wie AVB, Dante oder Soundgrid realisiert werden.
Weblinks
- Projekthauptseite (englisch)
Einzelnachweise
- ↑ Ohloh Analysis Summary - PulseAudio. Ohloh. Abgerufen am 14. Mai 2010.
- ↑ a b About Pulseaudio. freedesktop.org. Abgerufen am 17. September 2019.
- ↑ What is wrong with system mode? – PulseAudio. Abgerufen am 30. Juni 2022.
- ↑ Interviews/LennartPoettering. In: Fedora Project Wiki. 2. November 2007, abgerufen am 5. Februar 2008 (englisch).
- ↑ JD Mars: Better Latent Than Never. Abgerufen am 5. Februar 2008 (englisch).
- ↑ Releases/34/ChangeSet - Fedora Project Wiki. Abgerufen am 20. März 2022.
