Hi,
Xfce läuft bei Dir wohl auch nicht unter wayland?
@ralli hatte im "Pipewire Erfahrungen"-Thread einen älteren Artikel im Linux Magazin verlinkt[*]. (
viewtopic.php?t=179375&start=30#p1282751)
Da lässt sich ganz gut herauslesen, welche Zielsetzung mit der Entwicklung verbunden ist.
Kurz dargestellt kann man sagen, dass die Vorstellungen von Red Hat/IBM für den Linux-Desktop der Zukunft mit vollständigem Versandkasten der Anwendungen und gleichzeitigem Teilen von Video- und Audiogeräten unter Wayland eine andere Infrastruktur benötigt als die bisher gegebene. Im Idealfall soll diese Lösung wohl so aussehen wie Apples "coreaudio". One sound server to rule them all.
Die Tatsache das in diesem Zuge ein Problem von pulseaudio mit der Bereitstellung von real time audio Kapazitäten behoben werden soll, begeistert natürlich diejenigen, die möglichst einfach pro audio tools parallel zu Desktop-Anwendungen wie z.B. Firefox benutzen wollen.
Das erklärt vielleicht den Eindruck, es handele sich um eine Initiative der Pro-Audio-Fraggles.
Dazu muss man erwähnen, dass pulseaudio für Anwendungen mit real time audio Anforderungen absolut *nicht* brauchbar funktioniert. Es ist explizit *nicht* für dieses Einsatzszenario entwickelt worden.
Es gibt verschiedene Workarounds für solche Nutzungsanforderungen. Man kann seine Audioanwendung (z.B.
ardour) direkt über alsa mit der Soundkarte verbinden. Diese ist dann allerdings nicht mehr mit anderen Anwendungen teilbar. Man kann jack als sound server verwenden. Dann kann die Soundkarte mit anderen Anwendungen geteilt werden, die sich mit jack verbinden können. Oder man kann jack mit einer bridge zu pulseaudio konfigurieren. Dann können auch Anwendungen auf die Soundkarte zugreifen, die kein gateway zu jack besitzen oder gar explizit pulseaudio voraussetzen (prominentes Beispiel: firefox).
Alle diese Lösungen sind mit unterschiedlichen Nachteilen verbunden. Vor allem ist die Lösung mit einer bridge zu pulseaudio mit möglichen Einbußen hinsichtlich der Verzögerung und einer aufwendigen (fehleranfälligen) Konfiguration behaftet.
Meine Einschätzung, dass die real time audio Kapazitäten bei der Entwicklung von pipewire eher die zweite Geige spielen, ergibt sich auch aus dem git log des Projekts. So wurde z.B. das "latency reporting" des sound servers erst vor einigen Monaten implementiert. Diese Berechnung und transparente Weitergabe der Verarbeitungsverzögerung ist aber eine wesentliche Voraussetzung für jegliche Anwendung in diesem Bereich.
[*] Diese Diskussion wäre im erwähnten Faden offensichtlich besser aufgehoben.
Das Wem, Wieviel, Wann, Wozu und Wie zu bestimmen ist aber nicht jedermannns Sache und ist nicht leicht.
Darum ist das Richtige selten, lobenswert und schön.