# Habe PulseAudio durch PipeWire ersetzt...

## schmidicom

Hallo,

gestern habe ich auf meinem Laptop (unter anderem der Experimentierfreude zu liebe) den PulseAudio durch PipeWire ersetzt und wollte hier einfach mal meinen Weg dahin und meine Erfahrungen damit niederschreiben. Vielleicht erweist sich das für den einen oder anderen sogar als nützlich und/oder regt zu einer schönen Diskussion an.

----

Als erstes musste ich sicherstellen das der PulseAudio nicht mehr automatisch gestartet wird, was gar nicht so einfach war denn das Teil liefert gleich drei Möglichkeiten mit von denen zwei standardmäßig aktiv sind.

1. Autostart per XDG

Dieser Autostart war noch am einfachsten zu finden und es reicht völlig aus die Datei "/etc/xdg/autostart/pulseaudio.desktop" einfach zu löschen.

2. Autostart per Client-Konfiguration

Dieser Autostart ist echt hinterlistig und einfach mal so wirklich schwer zu finden. In der Datei "/etc/pulse/client.conf" muss die Option "autospawn" auf "no" stehen, dann wird der Dienst nicht automatisch gestartet sobald irgend ein Client versucht darauf zuzugreifen.

3. Autostart per systemd

Diese Methode ist offenbar standardmässig deaktiviert.

Trotzdem ist es ratsam mit "systemctl --user status pulseaudio.service pulseaudio.socket" nach zu sehen ob diese Methode wirklich inaktiv ist. Was dann so aussehen sollte:

```
● pulseaudio.service - Sound Service

     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)

     Active: inactive (dead)

TriggeredBy: ● pulseaudio.socket

● pulseaudio.socket - Sound System

     Loaded: loaded (/usr/lib/systemd/user/pulseaudio.socket; disabled; vendor preset: enabled)

     Active: inactive (dead)

   Triggers: ● pulseaudio.service

     Listen: /run/user/1000/pulse/native (Stream)
```

Und wer an dieser Stelle ganz sicher gehen will kann diese User-Units auch global für alle Benutzer maskieren:

```
pkexec systemctl --global mask pulseaudio.service pulseaudio.socket
```

----

Dann muss natürlich der PipeWire (am besten die aktuellste Version) mit den passenden USE-Flags installiert werden, bei mir sieht das zum Beispiel folgendermaßen aus:

```
media-video/pipewire-0.3.39::gentoo bluetooth -doc -echo-cancel extra gstreamer -jack-client -jack-sdk pipewire-alsa systemd -test v4l
```

----

Danach bin ich hingegangen und habe die nötigen PipeWire-Dienste aktiviert.

Hier gibt es zwei Möglichkeiten das zu machen, entweder nur für den aktuellen Benutzer oder global für alle Benutzer. Welche Variante für einen selbst nun besser passt muss jeder selber entscheiden, bei mir habe ich es für alle Benutzer (also global) aktiviert.

- Wenn es nur für den aktuellen Benutzer aktiviert werden soll:

```
systemctl --user enable pipewire.socket pipewire-pulse.socket wireplumber.service
```

- Wenn es stattdessen bei allen Benutzern aktiviert sein soll kann auch folgendes eingegeben werden:

```
pkexec systemctl --global enable pipewire.socket pipewire-pulse.socket wireplumber.service
```

----

Das wars, jetzt läuft bei mir das ganze über PipeWire und kein PulseAudio-Client merkt was davon das er jetzt mit was anderem arbeitet. Auch die Steuerung der Soundausgabe in meinem KDE Plasma funktioniert einwandfrei. So richtig positiv ist mir aber aufgefallen das beim Umgang mit Bluetooth-Geräten deutlich mehr Codecs (oder auch "Profile") zur Auswahl stehen als bei PulseAudio und auch der Wechsel von einer Ausgabe zur anderen läuft jetzt schneller und ohne irgendwelche Störgeräusche ab.

EDIT:

Was die verbleibende Abhängigkeit vieler Packages von media-sound/pulseaudio angeht, da müssten die Portage-Devs was machen. Am besten mit einer Massnahme wie sie im folgenden Kommentar vorgeschlagen wird:

https://bugs.gentoo.org/744622#c16Last edited by schmidicom on Mon Oct 25, 2021 2:57 pm; edited 4 times in total

----------

## Schattenschlag

Oh läuft pipewire schon stabil ? cool danke für das kleine howto ^^.... gleich mal selber testen

----------

## schmidicom

Nur so als kleiner Zwischenbericht:

Bis jetzt bin ich sehr zufrieden mit PipeWire, es ist mir noch kein einziges mal abgestürzt (zumindest wäre es mir nichts aufgefallen) und auch die Devs dahinter scheinen sehr aktiv zu sein. Die einzige etwas seltsame Eigenheit die mir aufgefallen ist, ist das manche Einstellungen (z.B. wenn eine bestimmte Anwendung vom der Standardausgabe/eingabe abweicht) nicht über einen Neustart hinweg gespeichert bleiben. Aber das stört mich nur minimal bis gar nicht, ist also kein Grund für mich zu Pulseaudio zurück zu wechseln.

Was mich mehr stört ist das ich wegen diversen Abhängigkeiten nach wie vor einen kompletten Pulseaudio installiert haben muss...

Hier wäre es wirklich schön wenn mal ebuild's daherkommen die es einem ermöglichen nur noch die Client-Library von Pulseaudio zu installieren.Last edited by schmidicom on Thu Sep 16, 2021 10:53 am; edited 1 time in total

----------

## mike155

Auch von mir ein "Danke" für das HOWTO!

Zurzeit läuft bei noch alles unter ALSA - also ohne Pulseaudio oder Pipewire. Aber wenn ich irgendwann wechseln muss, werde ich auf dieses HOWTO zurückgreifen.   :Smile: 

----------

## schmidicom

Kleines Update:

Habe in meinem ersten Post einige Anpassungen vorgenommen weil die Devs von Pipewire ihren Media-Session-Dienst in ein separates Paket ausgelagert haben und der dazugehörige Service nun einen anderen Namen hat.

Um ein Update sauber durchzuführen empfehle ich nach dem Update durch emerge noch folgende beiden Befehle abzusetzen um sicherzustellen das es auch weiterhin funktioniert:

```
systemctl --user disable pipewire-media-session.service
```

oder

```
pkexec systemctl --global disable pipewire-media-session.service
```

Und dann:

```
systemctl --user enable wireplumber.service
```

oder

```
pkexec systemctl --global enable wireplumber.service
```

----------

## flammenflitzer

Was mir unklar ist, wenn ich pipewire statt pulsaudio nutzen will, entferne ich dann vorher pulseaudio und alle gesetzten pulseaudio-flag?

----------

## schmidicom

 *flammenflitzer wrote:*   

> Was mir unklar ist, wenn ich pipewire statt pulsaudio nutzen will, entferne ich dann vorher pulseaudio und alle gesetzten pulseaudio-flag?

 

Habe ich bereits weiter oben angesprochen, und die Antwort lautet Nein.

PipeWire liefert nur einen mit Pulseaudio kompatiblen Sound-Server, aber die von den Anwendungen benutzte/benötigte Client-Library ist aktuell nur in "media-sound/pulseaudio" enthalten. Und gerade da finde ich das die Gentoo-Devs dem Package "media-sound/pulseaudio" ein minimal USE-Flag spendieren sollten welches bewirkt das nur noch die Client-Library installiert wird.

----------

## schmidicom

Inzwischen haben die Gentoo-Devs eine wirklich schöne Änderung ausgerollt (ist nicht ironisch gemeint).  :Smile: 

Das Paket "media-sound/pulseaudio" ist jetzt nur noch eine Art META-Package und der frühere Inhalt wurde in zwei andere Packages aufgeteilt:

- "media-libs/libpulse" enthält die Client-Library

- "media-sound/pulseaudio-daemon" enthält den Sound-Server

Jetzt muss beim META-Packages "media-sound/pulseaudio" nur das USE-Flag "daemon" deaktiviert werden und schon wird auch nur noch die Client-Library installiert.

----------

## forrestfunk81

 *pipewire.org wrote:*   

> 
> 
> PipeWire was designed with a powerful security model that makes interacting with audio and video devices from containerized applications easy
> 
> 

 

Das klingt interessant. Ich will zwar kein Flatpack, aber ich hätte gerne dass mehrere X Sessions und Qemu VMs gleichzeitig die selbe Soundkarte nutzen. Anwendungszweck z.B. Musik streaming unter Linux und gleichzeitiges Zocken in der Windows VM. Das geht auch mit Pulseaudio ist aber alles ziemlich hacky. 

 *Quote:*   

> The PipeWire PulseAudio server has fairly complete network support. The only module that is not yet implemented is the RTP network streaming module (but the ROC module is an alternative).

 

Das muss ich mir mal genauer ansehen. Aber zur Zeit ist das Wetter zu schön  :Wink: 

----------

