CleanPress

Schlagwort: Pipewire

  • WirePlumber: ein Session-Manager für PipeWire

    WirePlumber: ein Session-Manager für PipeWire

    Den meisten Lesern dürfte PipeWire als designierter Nachfolger von PulseAudio und mehr mittlerweile ein Begriff oder bereits in Benutzung sein. Ein Artikel von 2018 in der Zeitschrift LinuxUser beleuchtet die Notwendigkeit für die Entwicklung von PipeWire im Zusammenspiel mit der fortschreitenden Wayland-Integration. Seither ist viel passiert und PipeWire produktiv nutzbar geworden.

    Der Klempner

    Kürzlich erschien nun unter der treffenden Bezeichnung WirePlumber ein externer Session-Manager für PipeWire, der mit Fedora 35 ausgeliefert wurde und der auch bei mir bereits bei Debian Unstable Dienst tun. Ich kam auch gar nicht drum herum, da die bis dahin dafür verwendete Komponente pipewire-media-session entfernt wurde und in der Folge der Sound ausblieb.

    Für den Automotive-Bereich entwickelt

    WirePlumber wird von dem bei Collabora angestellten George Kiagiadakis entwickelt, der seit 2018 auch an PipeWire mitarbeitet. Eines der weiteren Projekte, an denen er im Rahmen seiner Anstellung arbeitet, ist das unter dem Schirm der Linux Foundation agierende Automotive Grade Linux (AGL). Hier fiel ihm auf, dass das zuverlässige Regeln von mehreren Audioströmen mit PulseAudio nicht einfach war. Dabei ging es um simple Dinge wie das Herunterregeln der Lautstärke der Musik, wenn eine Sprachmeldung vom Navi anstand oder das Stoppen des Audiostroms, wenn ein Anruf hereinkommt.

    Logik per Lua-Script

    Für diese Aufgaben versprach PipeWire bessere Ergebnisse. Allerdings stellte Kiagiadakis fest, dass der verwendete, in C geschriebene Session-Manager pipewire-media-session zu unflexibel war, wenn es um schnelle Anpassungen am Code ging. In der Folge entwarf er WirePlumber als modulare externe Anwendung, deren Steuerlogik in der Scriptsprache Lua verfasst ist. Diese Lua-Skripte können leicht modifiziert und erweitert werden, was bedeutet, dass die Benutzer jetzt die Möglichkeit haben, das Verhalten ihres PipeWire-Setups besser an ihre Bedürfnisse anzupassen.

    Raue Ecken

    Noch gibt es allerdings einige raue Ecken, die ausgebügelt werden müssen, bevor WirePlumber ein guter Mitspieler auf dem Desktop wird. Aber die Auslieferung mit Fedora 35 sollte hier für schnellen Fortschritt sorgen. Red Hat-Entwickler Christian Schaller hat Kiagiadakis für das Fedora Magazine zu WirePlumber interviewt, der einige Hintergründe der Entwicklung erläutert. Die Dokumentation von WirePlumber beleuchtet weitere technische Einzelheiten wie die Konfiguration und die einzelnen Module.

    Mit der rasanten Entwicklung von PipeWire und dem neuen Session-Manager WirePlumber sehen wir, wie ich finde, spannenden Zeiten im Bereich Audio/Video entgegen.

    Bild: Photo by Bruce Warrington on Unsplash

  • Debian: PulseAudio mit PipeWire ersetzen

    Debian: PulseAudio mit PipeWire ersetzen

    PipeWire Debian
    Bild: Fedora

    In den nächsten Monaten und Jahren wird unter Linux PipeWire, das neue Low-Level-Multimedia-Framework bei Audio und Video das Ruder übernehmen. Es soll Aufnahme und Wiedergabe sowohl von Audio als auch von Video mit minimaler Latenz und Unterstützung für PulseAudio-, JACK-, ALSA- und GStreamer-basierte Anwendungen bieten. Gerade hat Fedora 34 offiziell den Anfang gemacht und PipeWire als Standard bei Audio gesetzt. In einigen Bereichen wie Screen-Sharing und Remote Desktop unter Wayland war das bereits vorher der Fall.

    Anwendungsszenarien

    Ich habe PipeWire in Debian Sid (siduction) seit geraumer Zeit die Kontrolle übergeben und für meine Anwendungsszenarien funktioniert das recht gut. Unter Ubuntu habe ich einen kurzen Test mit ebenfalls zufriedenstellendem Ergebnis durchgeführt. Dabei starte ich in siduction KDE Plasma üblicherweise in eine Wayland-Sitzung, aber es funktioniert genauso gut unter X.org.

    PipeWire kommt bei mir zum Hören von Musik über eine angeschlossene Stereo-Anlage als auch über Bluetooth-Kopfhörer, bei Videokonferenzen und am Rande auch bei Audio-Editing mit Audacious zum Einsatz. Der jetzige Stand von PipeWire erlaubt dies ohne größere Schmerzen und aus meiner Sicht nicht schlechter als PulseAudio.

    Buster außen vor

    In Debian Stable (Buster) hängt PipeWire mit Version 0.2.5-1 reichlich zurück, während in Testing und Unstable (sid) 0.3.19-4 und in Experimental 0.3.25-1 verfügbar sind. Fedora 34 nutzt die auch im Git vor einer Woche veröffentlichte aktuelle Version 0.3.26-1. Damit scheidet Stable wegen der zu alten Version zum aussagekräftigen Testen vermutlich aus, das habe ich aber nicht getestet. Zunächst habe ich 0.3.19-4 aus Unstable und anschließend 0.3.25-1 installiert, beide zeigten keine groben Fehler.

    Pipewire selbst sollte bereits installiert sein. Falls nicht:

    sudo apt update && sudo apt install pipewire

    Seit PipeWire 0.3.5 sind einige Bibliotheken in dem Paket pipewire-audio-client-libraries zusammengefasst. Die Paketbeschreibung sagt darüber:

    Dieses Paket enthält Client-Bibliotheken, die es Programmen, die für ALSA-, JACK- und PulseAudio-APIs entwickelt wurden erlauben, einen PipeWire-Server für die Wiedergabe und Aufnahme verwenden zu können. Sie werden standardmäßig nicht verwendet und sind derzeit als experimentell angesehen.

    apt show pipewire-audio-client-libraries

    Ich habe alle Warnungen in den Wind geschlagen und konnte bisher keine Probleme feststellen. 

     sudo apt install pipewire-audio-client-libraries

    Um Bluetooth-Funktionalität mit PipeWire zu erhalten, wird ein weiteres Paket benötigt:

    sudo apt install libspa-0.2-bluetooth

    Wenn Unterstützung für den Sound-Server JACK benötigt wird, dann fehlt noch:

    sudo apt install libspa-0.2-jack

    Soweit die benötigten Pakete, nun geht es an die Konfiguration. Folgende Schritte sind nötig, um PulseAudio durch PipeWire zu ersetzen: 

    # touch /etc/pipewire/media-session.d/with-pulseaudio
# cp /usr/share/doc/pipewire/examples/systemd/user/pipewire-pulse.* /etc/systemd/user/

    Die folgenden drei Befehle werden als User, nicht als Root ausgeführt. Damit deaktiviert ihr PulseAudio und setzt PipeWire an seine Stelle:

    systemctl --user daemon-reload
systemctl --user --now disable pulseaudio.service pulseaudio.socket
systemctl --user --now enable pipewire pipewire-pulse

    Den Erfolg könnt ihr folgendermaßen überprüfen:

    pactl info | grep '^Name des Servers'

    Der Befehl sollte eine Zeile mit PulseAudio (on PipeWire 0.3.19) zurückgeben. Sollte dies nach einem Reboot keinen Bestand haben, muss der PulseAudio-Service maskiert werden:

    systemctl --user mask pulseaudio

    Darauf sollte ein weiterer Reboot folgen. Auch ALSA-Clients können für die Nutzung von PipeWire konfiguriert werden: 

    # touch /etc/pipewire/media-session.d/with-alsa
# cp /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d/

    Bei JACK sieht es ähnlich aus:

    # touch /etc/pipewire/media-session.d/with-jack
# cp /usr/share/doc/pipewire/examples/ld.so.conf.d/pipewire-jack-*.conf /etc/ld.so.conf.d/
# ldconfig

    Danach lassen sich Multimedia-Dateien über die entsprechenden Anwendungen abspielen. PipeWire wäre aber nicht Linux, wenn nicht auch die Nutzung per Terminal möglich wäre. Hierzu stehen Befehle wie pw-cat, pw-play und pw-record zur Verfügung.

    Wenn etwas nicht läuft, hilft oft ein Blick auf:

    systemctl --user status pipewire.service
und wenn nötig
systemctl --user restart pipewire-pulse.service

    Ich habe dort einige Fehler bezüglich ALSA, die mich nicht stören und denen ich noch nicht nachgegangen bin. Bitte bedenkt: Jeder Soundchip kann unterschiedliche Ergebnisse hervorbringen, immerhin ist PipeWire noch nicht bei einer stabilen 1.0 angekommen.

    Bluetooth, Flatpaks und PulseEffects

    Mehr brauchte ich nicht zu tun. Meine Marshall Bluetooth-Kopfhörer waren schneller verbunden als früher. Nach der Installation des Pakets xdg-desktop-portal-kde funktioniert PipeWire auch mit Flatpaks. Bei GTK-basierten Distributionen nimmt man entsprechend xdg-desktop-portal-gtk.

    Das einzige, was derzeit bei mir nicht funktioniert, ist PulseEffects, das in Version 4.8.4-1 installiert ist und eigentlich mit gstreamer1.0-pipewire laufen sollte. Ich erhalte aber ständig einen Speicherzugriffsfehler. Mittlerweile wurde für die Verwendung mit PipeWire EasyEffects als Ersatz für PulseEffects veröffentlicht.

  • PulseAudio 14.0 freigegeben

    PulseAudio 14.0

    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.
    • Verbesserte Unterstützung für den ALSA Use Case Manager (UCM).
    • 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 34 soll Audio über PipeWire ausgeben

    PipeWire in Fedora 34
    By: DocChewbacca – CC BY-SA 2.0

    Wenn es nach einem Vorschlag für Fedora 34 geht, sollen ab dem nächsten Frühjahr alle Audio-Ströme über PipeWire ausgegeben werden. Fedora wäre dann die erste Distribution, die PipeWire als Audio-Standard einsetzt.

    PipeWire ist ein Framework für Audio und Video, das 2017 erstmals öffentlich vorgestellt wurde. Angesichts des Anzeigeprotokolls Wayland und des alternativen Paketformats Flatpak soll es künftig die Rolle der Audio- und Videoausgabe auf sich vereinen. Entwickelt wird PipeWire von dem bei Red Hat beschäftigen Wim Taymans, einem Veteranen der GStreamer-Entwicklung. Das Framework basiert auf einer neuen API namens Simple Plugin API, kurz SPA.

    Wayland und Flatpak

    Gerade bei Wayland hilft PipeWire dabei, die Streams bei Screen-Recording und Screen-Sharing auszugeben, da die aus Sicherheitsgründen unter Wayland fehlende Netzwerktransparenz neue Lösungen erfordert. Auch bei der Ausgabe von Audio- und Video-Dateien in Containern wie Flatpak ist PipeWire gefragt. Dabei soll es transparent und sicher Audoio- und Video-Ströme innerhalb und außerhalb der Sandbox lenken.

    Desktop- und Pro-Audio vereint

    Der Änderungsvorschlag für Fedora 34 stammt ebenfalls von Taymans und sieht vor, die Audioströme von Desktop-Anwendungen sowie von professionellen Tools mit PipeWire auszugeben. Damit wird der Audio-Daemon von PipeWire die Funktionalität der Daemons von PulseAudio, dem Sound-Server Jack und ALSA übernehmen. Realisiert wird das über PipeWire-kompatible Clients für die verschiedenen Anwendungen. Für ältere ALSA-Clients wird ein ALSA-Plugin den Ton direkt an PipeWire weiterleiten. Damit werden die Daemons von PulseAudio und Jack überflüssig.

    Für Fedora 34 fraglich

    Liest man die Einwände anderer Entwickler auf der Mailingliste, so ist fraglich, ob der Vorschlag für Fedora 34 umgesetzt wird. Die meisten Kommentare votieren für eine Verschiebung auf Fedora 35 im nächsten Herbst. Andere sind der Meinung, da es einen Rückfallplan gibt, sei es an der Zeit, PipeWire einem breiteren Publikum vorzustellen. Einen ausführlichen Artikel zu PipeWire habe ich 2018 veröffentlicht.

  • Aktuelle Entwicklungen bei Fedora Workstation

    Screenshot: FThommes

     

    In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.

    Wayland im Hintergrund

    Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.

    Entfernte Desktops laden

    Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.

    Desktop-Sharing per WebRTC

    Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.

    PipeWire

    Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.

    Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von  PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.

    GNOME Builder im Container

    GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE«  der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.

  • Screensharing unter Wayland erklärt

    Screensharing unter Wayland erklärt

    Bereits im März berichteten wir über die Bemühungen von Red-Hat-Entwickler Jan Grulich, Screensharing für KDE-Plasma unter Wayland zu realisieren. Da Wayland im Gegensatz zu X11 kein Netzwerkprotokoll ist, müssen für das Screensharing unter Wayland neue Wege gefunden werden. Dafür hatte Grulich bereits Backends in Form von xdg-desktop-portal und xdg-desktop-portal-[kde/gtk] für KDE-Plasma und die GNOME-Shell geschrieben und das Audio-Video-Framwork PipeWire zum Streamen auserkoren. Was fehlte, war eine Anwendung, mit der ein User Screensharing auch nutzen konnte.

    WebRTC als Screensharing-Anwendung

    Seit einigen Wochen arbeitet Grulich mit zwei Kollegen, daran, für diese Aufgabe die in Browsern verwendete Videochat-Technik WebRTC nutzbar zu machen, wie er jetzt in seinem Blog berichtet. WebRTC verwendet eine Klasse namens DesktopCapturer, die sowohl unter X11 als auch den Gegenstücken bei Windows oder macOS Verwendung findet. Diese Klasse hat das Team nun für Wayland aufgebohrt.

    Alle Bauteile zusammen

    Die Umsetzung dieser Idee unter Verwendung der Portals für Plasma und GNOME sowie PipeWire als Streaming-Agent konnte relativ einfach umgesetzt werden. Dank der Backend-Portals wird diese Technik auch in Sandboxen in Flatpak oder Snap funktionieren. Allerdings müssen die leicht unterschiedlichen Herangehensweisen der Browser an WebRTC noch angepasst werden, bevor der Code produktiv genutzt werden kann. Für Neugierige hat Grulich für Fedora ein Repository aufgesetzt, dass einen Firefox mit den entsprechenden Änderungen enthält.  Voraussetzung ist lediglich ein funktionierendes PipeWire.

    Screensharing unter Wayland

    Ein zweiter Blogeintrag von Grulich geht in die Praxis und erläutert schrittweise, wie Screensharing mit Wayland bereits jetzt auch außerhalb von Fedora genutzt werden kann. Wird der Plasma-Desktop verwendet, so wird hier Version 5.13.2 vorausgesetzt. Sowohl die GNOME-Shell als auch Plasma brauchen noch ein wenig Anpassung, wie Grulich erläutert. Der Blogeintrag bietet zudem für Interessierte am Ende einige Verweise, die das grundlegende Verständnis der verwendeten Techniken vertiefen sollen.

  • Plasmas Wayland-Session lernt Screen-Sharing

    Plasmas Wayland-Session lernt Screen-Sharing

    Wayland Screen-Sharing
    Bild: Fedora

    Ein generelles Defizit von Wayland ist das Fehlen von Netzwerktransparenz. Diese aus Sicherheitserwägungen fehlende Funktionalität bedeutet, dass das Wayland-Protokoll keine Lösung für etablierte Techniken wie Screen-Recording und -Sharing mitbringt. Diese Funktionalität muss bei Wayland über die Compositoren gegeben sein. Fedora- und KDE-Entwickler Jan Grulich arbeitet an der Bereitstellung dieser Funktionalität unter Plasma. Hierbei kommt neben einer neuen API auch das neue Multimedia-Framework Pipewire ins Spiel.

    API für Wayland Screen-Sharing

    Eine der Gründe für die Entwicklung von Pipewire war die Unterstützung von gewohnter Funktionalität, die unter anderem bei Flatpak und Wayland aus Sicherheitsaspekten einem neuen Ansatz folgen muss. Die benötigte API für Screen-Recording und -Sharing und Remote-Desktop wurde unlängst in das xdg-desktop-portal eingefügt. Mit Hilfe dieser API können Anwendungen nun auf Ihren Bildschirminhalt in Wayland-Sitzungen oder in Sandboxen wie bei Flatpak zugreifen.

    [su_slider source=“media: 4385″ link=“image“ width=“700″ height=“460″ mousewheel=“no“ autoplay=“0″ speed=“0″]

    Mit verschiedenen Backend-Implementierungen wie xdg-desktop-portal-kde oder xdg-desktop-portal-gtk muss nur eine einzige API unterstützt werden, um alle Desktops anzusprechen. Das Screen-Cast-Portal beispielsweise funktioniert so, dass der Client zunächst eine Sitzung mit der Backend-Implementierung des xdg-desktop-portal (xdp) erstellt.

    Pipewire liefert den Stream

    Der Benutzer erhält dann einen Dialog zur Freigabe des Bildschirms, den er freigeben möchte und startet damit die Bildschirmfreigabe. Sobald er das getan hat, erstellt die xdp-Backend-Implementierung einen Pipewire-Stream, sendet die Antwort an den Client mit Stream-ID zurück und der Client kann sich mit dieser ID mit dem Stream verbinden und seinen Inhalt abrufen.

    Grulich hat vor wenigen Tagen die Unterstützung für das Screen-Cast-Portal für das xdg-desktop-portal-kde in den KDE-Phabricator eingebracht und wartert derzeit auf das Ergebnis des Reviews. Er hofft, der Code könne früh genug für Plasma 5.13 freigegeben werden, dessen Veröffentlichung für den 12. Juni geplant ist.

  • Multimedia-Framework PipeWire auf gutem Weg

    Multimedia-Framework PipeWire
    Bild: Fedora

     

    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.

     

  • Fedora 27 Workstation Beta freigegeben

    Fedora 27 Workstation
    Screenshot: FThommes

    Normalerweise gebührt die Ehre, eine neue GNOME-Version zuerst offiziell in einer Distribution vorzustellen Red Hats Experimentierstube Fedora. Doch jetzt gibt es Konkurrenz. Canonical ist zu GNOME als Standard-Desktop zurückgekehrt und hat vor wenigen Tagen die Beta-Version zu Ubuntu 17.10 Artful Aardvark mit GNOME 3.26 veröffentlicht. Nun zieht Fedora, Red Hats Entwicklungslabor, dreimal um eine Woche verzögert, mit der Beta zu Fedora 27 Workstation nach. Es ist dies die erste Fedora-Version, die ohne Alpha-Version auskommt. Für die Beta-Version fehlt zudem wegen eines Fehlers, der bis zum Release behoben werden soll, die 32-Bit-Variante der Workstation.

    Fedora 27 Workstation
    Screenshot: FThommes

    Aktueller Unterbau

    Fedora 27 erscheint mit Kernel 4.13.3 und Systemd 234.7 als Basis. Firefox ist in Version 54 an Bord, LibreOffice in Version 5.4 mit dabei. Neben den Neuerungen von GNOME 3.26 wurden wie üblich unter anderem  Perl 5.26, Golang 1.9, Glibc 2.26, Boost 1.64.0, RPM 4.14, Node.js 8.x, Ruby on Rails 5.1 und PHP 7.2 als aktualisierte Versionen ausgeliefert. OpenJDK9, das als technische Vorschau ausgeliefert werden sollte, hat es nicht mehr in die Beta geschafft. Die Installationsmedien beherrschen jetzt auch 32-Bit UEFI-Support. Damit werden Geräte mit 64-Bit-CPU bedient, die mit 32-Bit-UEFI-Firmware ausgeliefert werden. Eine weitere Verbesserung ist die Unterstützung für den TRIM-Befehl auch auf verschlüsselten SSDs. Der Fedora Media Writer wurde um die Möglichkeit erweitert, bootfähige SD-Karten für ARM-Geräte zu erstellen. Zudem sollen mehr Anwendungen als zuvor als Flatpaks angeboten werden. Neu ist auch eine Vorabversion des neuen Multimedia-Frameworks Pipewire, das Audio und Video beherrscht und einmal PulseAudio beerben soll. Derzeit funktioniert aber lediglich der Video-Part.

    Fedora 27 Server erst in zwei Wochen

    Heute wurde neben Fedora 27 Beta auch die Cloud- und Container-Variante Fedora Atomic Host freigegeben. Die Server-Variante wird ausnahmsweise erst in rund zwei Wochen veröffentlicht. Hier findet gerade eine Modularisierung im Rahmen des Projekts Boltron statt. Fedora Workstation 27 steht ebenso zum Download bereit wie Atomic Host und diverse Spins mit alternativen Desktops. Die Veröffentlichung der stabilen Version ist derzeit für den 7. November vorgesehen.

  • Multimedia-Framework Pipewire soll PulseAudio ersetzen

    Structure
    By: DocChewbacca – CC BY-SA 2.0

    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.