Im Zusammenhang mit der News zu PipeWire als neuer möglicher Standard für alle Audioströme in Fedora 34 soll nicht unerwähnt bleiben, dass gestern mit PulseAudio 14.0 eine neue Version des derzeitigen Sound-Servers PulseAudio freigegeben wurde. Nach über einem Jahr Entwicklung hat PulseAudio 14.0 ein umfangreiches Changelog zu bieten. Dazu zählen unter anderem:
Ein Jahresvorrat an Änderungen
Umfassende Änderungen beim Routing für Sinks und Quellen (Sinks sind in dem Fall etwa Lautsprecher oder Kopfhörer).
Das automatische Umschalten des Audioausgangs auf HDMI ist jetzt standardmäßig wieder deaktiviert. Die Änderung war bei PulseAudio 13.0 unbeabsichtigt aktiviert war und wurde als störend empfunden.
USB-Spiele-Headsets für Geräte wie Razer Kraken Tournament Edition, SteelSeries Arctis 5, SteelSeries Arctis Pro, LucidSound LS31 und HyperX Cloud Orbit S werden nun besser unterstützt.
Flat Volumes sind künftig standardmäßig deaktiviert. Damit werden einige Applikationen daran gehindert, beim Start die Lautstärke auf 100 Prozent zu setzen.
Fedora 27 lieferte erstmals das neue Multimedia-Framework PipeWire aus. Die Anwendung soll für Audio und Video das leisten, was heute PulseAudio heute für Audio zu bieten hat. Darüber hinaus sollen auch professionelle Szenarien unter Einbeziehung des Soundservers Jack abgedeckt werden, die über die Funktionalität von PulseAudio hinausgehen. Begonnen hat die Entwicklung bereits vor einigen Jahren.
GStreamer als Vorbild
Entwickler Wim Taymans, der für Red Hat arbeitet, hatte bereits bei der Entwicklung von GStreamer federführend mitgearbeitet. Mit dem Aufkommen des alternativen Paketmodells Flatpak suchte er nach einer Möglichkeit, diesen Desktop-Containern – denn nichts anderes ist Flatpak – die Soundausgabe per PulseAudio zu ermöglichen. Im Anschluss begann er die Arbeit an PulseVideo, um das Gleiche auch für Bewegtbilder umzusetzen.
Im Endeffekt fiel die Entscheidung, Audio und Video in einem Framework zu bündeln, das den Namen PipeWire erhielt. Jetzt hat Red-Hat-Kollege Christian Schaller die gerade stattfindende Fedora-Entwicklerkonferenz DevConf 2018 im tschechischen Brno zum Anlass genommen, anlässlich eines Gesprächs mit Wim Taymans über die Fortschritte bei PipeWire in seinem Blog zu berichten.
Flatpak und Wayland profitieren
Mittlerweile sind es nicht nur mehr Flatpak oder Container im Allgemeinen, die auf ein modernes Framework angewiesen sind, um den Zwängen einer Sandbox gerecht zu werden und containerisierten Anwendungen die Ausgabe von Audio und Video über den Host trotzt Restriktionen zu ermöglichen. Auch Wayland braucht im Bereich Multimedia neue Lösungen, will es die Funktionalität von Xorg besser abdecken.
Das Anzeige-Protokoll Wayland ist mit mehr Augenmerk auf Sicherheit konzipiert als das rund 30 Jahre alte Netzwerkprotokoll X11. Aus diesem Grund wurde auch standardmäßig keine Netzwerktransparenz implementiert. Das bedeutet, dass das Wayland-Protokoll von Hause aus heute selbstverständliche Dinge wie Screensharing und -recording oder Remote Desktop per RDP oder VNC nicht unterstützt. Es gibt Anstrengungen, auch für Oberflächen von Wayland-Anwendungen die Verwendung über das Netzwerk zu realisieren. Eine davon nennt sich Waltham und wird bei Collabora entwickelt. Hier geht es aber in erster Linie vorerst nicht um den Desktop, sondern um den Automobilbereich.
Screensharing und Remote Desktop
Eine weitere Entwicklung in diese Richtung, die wiederum PipeWire ins Spiel bringt, wird von Red Hats Jonas Ådahl vorangetrieben und soll diese Funktionalität für GNOME zurückbringen. Da die Funktion im Compositor verankert ist, wird sie auch von anderen Desktop-Umgebungen nutzbar sein, die Wayland einsetzen. Das ist zwar alles noch im experimentellen Stadium, aber PipeWire beherrscht bereits rudimentär das Teilen von Geräten, wie Entwickler Taymans am Beispiel der Videoanwendung Cheese und PipeWire im Terminal demonstrierte. Zwei Anwendungen teilen sich dabei eine Webcam ohne sich gegenseitig zu stören. Dabei kommt ein PipeWire-GStreamer-Plugin zum Einsatz, was die Anpassung an die jeweilige Anwendung übernimmt.
Als Nächstes soll PipeWire zeitnah an Firefox und Chrome angepasst werden um Konferenzsoftware damit unter Wayland lauffähig zu bekommen. Der Sound-Server Jack für professionelle Ansprüche wie etwa geringe Latenzen wurde mittlerweile als Protokoll auf PipeWire draufgesetzt, sodass kein extra Jack-Server mehr vonnöten ist. Auf der Cosumer-Seite ist Bluetooth-Untzerstützung gegeben, wobei ein PipeWire-Bluetooth-Modul sich direkt mit dem Bluez-Bluetooth-Framework verbindet.
Aussichten
PulseAudio-Applikationen sollen nach den Plänen der Entwickler zunächst Sound über PipeWire ausgeben. Für GStreamer-Apps stellt sich die Frage nicht, da sie nativ PipeWire nutzen. Für Apps, die noch ALSA verlangen, soll es ein PipeWire-ALSA-Layer geben so wie es jetzt ein PulseAudio-ALSA-Layer gibt. PulseAudio soll im späteren Verlauf einmal überflüssig werden, was jedoch einige Jahre dauern wird. Für das im Mai anstehende Fedora 28 soll zumindest der Video-Part ausgeliefert werden, weitere Schritte sollen mit den nächsten Veröffentlichungen folgen.
GNOME-Entwickler Christian Schaller gab in seinem Blog die Freigabe des Projekts Pipewire bekannt, das er bereits des öfteren in Blogposts erwähnt hatte. Pipewire will über PulseAudio hinausgehen, indem es professionelle Lösungen in Bezug auf den Soundserver Jack bietet, die PulseAudio vermissen lässt. Zudem unterstützt Pipewire auch den Bereich Video. Zudem bietet es ein Sicherheitsmodell, dass die Interaktion mit containerisierten Anwendungen erleichtert, wobei der Fokus auf Flatpak liegt. Es erübrigt sich wohl zu erwähnen, dass Pipewire mit Wayland kompatibel ist.
Langfristig Ersatz für PulseAudio
Federführend entwickelt wurde Pipewire von GStreamer-Co-Entwickler Wim Taymans , der wie Schaller bei Red Hat angestellt ist. Taymans arbeitete dort bereits an einem Sicherheitsmodell für PulseAudio, um containerisierten Anwendungen zu erlauben, Sound per PulseAudio auszugeben. Im Verlaufe dessen begann er auch eine Anwendung zu schreiben, die er anfänglich PulseVideo nannte. Dabei erinnerte er die Schwierigkeiten bei der Entwicklung von GStreamer, Audio und Video synchron zu halten und entschloss sich, den Audio-Part ebenfalls neu zu schreiben.
Professionelle Einsatzszenarien
Dabei sollte Pipewire auch professionelle Einsatzszenarien im Zusammenahng mit Jack abdecken, die PulseAudio nie bedient hat. Aber nicht nur dieses neue Ziel verlängerte die Entwicklungszeit, wie Schaller schreibt, sondern auch die Tatsache, dass für Wayland eine sichere Methode des Screen-Capturing von simplen Screenshots bis zu Screencasts und Remote-Protokollen erstellt werden musste.
Bereit für Wayland
Wayland-Entwickler Jonas Ådahl schuf dafür eine API, die im Wayland-Compositor unterstützt wird und Pipewire zur Ausgabe nutzt. Dabei beschränkt sich die Unterstützung für Remote-Protokolle nicht auf einzelne Protokolle wie RDP oder VNC, sondern bietet eine Infrastruktur, auf der Protokolle aufsetzen können. So soll etwa auch Spice von der Entwicklung profitieren.
Stand der Entwicklung
Pipewire wird nach mehreren Jahren Entwicklungszeit mit dem voraussichtlich am 24. Oktober veröffentlichten Fedora 27 erstmals ausgeliefert. Die erste Implementation wird nur Video unterstützen, da hier der Bedarf für Wayland und Flatpaks am größten ist. Die Auslieferung von Audio-Funktionalität mit Pipewire wird noch einer Menge Arbeit bedürfen. Schallert erinnert an die mit vielen Problemen behaftete Einführung von PulseAudio und möchte diese Geschichte nicht wiederholt sehen. Pipewire kann bereits in der Beta-Version zu Fedora 27, die am 26. September erscheinen soll, getestet werden. Im Pipewire-Wiki findet sich eine anfängliche Dokumentation zum Projekt.
