[Gelöst] In inxi wird nur alsa als Soundserver angezeigt

[ralli]

Hallo,

ich habe pipewire nach unserem Wiki eingerichtet:

Debian 11 Bullseye Pipewire konfigurieren

In diesem Szenario wird PipeWire als Audiodienst pro Benutzer ausgeführt und ersetzt PulseAudio vollständig.

Erstellen Sie diese leere Datei:

als Root

Code: Alles auswählen

# touch /etc/pipewire/media-session.d/with-pulseaudio

Erstellen Sie einen Pipewire-Impulsdienst, indem Sie die Beispieldateien kopieren:

als Root

Code: Alles auswählen

# cp /usr/share/doc/pipewire/examples/systemd/user/pipewire-pulse.* /etc/systemd/user/

Führen Sie diese drei Befehle als Ihr normaler Benutzer (nicht als root) aus:

// Auf neue Servicedateien prüfen mit:

Code: Alles auswählen

systemctl --user daemon-reload

// Deaktivieren und stoppen Sie den PulseAudio-Dienst mit:

Code: Alles auswählen

systemctl --user --now disable pulseaudio.service pulseaudio.socket

// Aktivieren und starten Sie den neuen Pipewire-Pulse-Dienst mit:

Code: Alles auswählen

systemctl --user --now enable pipewire pipewire-pulse

Sie können überprüfen, welcher Server verwendet wird, indem Sie als normaler Benutzer Folgendes ausführen:

Code: Alles auswählen

LANG=C pactl info | grep '^Server Name'

Wenn es PipeWire verwendet, lautet der Servername „PulseAudio (auf PipeWire 0.3.19)“.

also Server Name: PulseAudio (on PipeWire 0.3.19)

Stellen Sie sicher, dass dies nach einem Neustart weiterhin funktioniert. Wenn nicht, müssen Sie den PulseAudio-Dienst möglicherweise "maskieren", indem Sie Folgendes ausführen:

Code: Alles auswählen

systemctl --user mask pulseaudio

Dies kann einen weiteren Neustart erfordern, nach dem ausschließlich PipeWire verwendet werden sollte, auch nach weiteren Neustarts. Dadurch wird die Aktivierung des PulseAudio-Dienstes sofort blockiert. Wenn Sie die vorherige Funktionalität wiederherstellen möchten, müssen Sie denselben Befehl erneut mit der Aktion "demaskieren" ausführen.

Status: OK

Hier nun die Überprüfung per Konsole:

Code: Alles auswählen

inxi -A

Audio:

  Device-1: NVIDIA GK208 HDMI/DP Audio driver: snd_hda_intel 
  Device-2: Creative Labs Sound Core3D [Sound Blaster Recon3D / Z-Series] 
  driver: snd_hda_intel 
  Sound Server: ALSA v: k5.10.0-14-amd64 
  
ralph@debian:~$ LANG=C pactl info | grep '^Server Name'

Server Name: PulseAudio (on PipeWire 0.3.19)

Wie kommen die unterschiedlichen Infos zustande? Was ist richtig?

Inxi zeigt alsa als Soundserver und der zweite Befehl PulseAudio (on PipeWire 0.3.19).

Bin gerade etwas irritiert, was ist denn nun richtig?

Gruß ralli

[novalix]

Howdy,

ALSA ist das Kernel-Subsystem für das Verarbeiten von Audio-Signalen. Es ist die Voraussetzung für jegliche user space Software, die Klang verarbeiten will. Dazu gehört auch die darauf aufsetzende Bibliothek libasound und die alsa-tools als Anwenderschnittstelle.
Es ist deshalb etwas irreführend, dass inxi ALSA als "sound server" bezeichnet, wenn man "server" als Synonym für "daemon" versteht; also ein user space Programm, welches als Hintergrundprozess arbeitet und eine Schnittstelle für im Vordergrund arbeitende Anwenderprogramme bietet.
Das ist genau die Aufgabe von jackd, pulseaudio oder eben pipewire. Das sind allesamt daemons, die eine Schnittstellenabstraktion zum Kernel-Subsystem ALSA für audio verarbeitende Frontend-Programme bieten. Diese bezeichnet man gemeinhin als sound server.
Nebenbei:
Anwenderprogramme können durchaus auch auf die Schnittstellenabstraktion der sound server verzichten und die Kernelschnittstelle (ALSA) direkt ansprechen (bzw. Funktionen der libasound aufrufen).

Grundsätzlich: ALSA ist immer im Spiel, wenn sound verarbeitet wird, ob mit oder ohne vermittelnden daemons.

Pipewire ist so konzipiert, dass es für bereits vorhandene Programme, die eine Schnittstelle zu pulseaudio bzw. jackd besitzen, transparent fungiert. Das klappt im allgemeinen, aber (noch) nicht in jedem Einzelfall.
Gemeint ist damit, dass ein Programm wie

Code: Alles auswählen

pactl

(pulseaudio control) auch dann funktioniert, wenn der eigentliche daemon "pulseaudio" gar nicht installiert ist bzw. aktiv ist, sondern eben pipewire mit seiner transparenten Schnittstelle. Das gleiche gilt dann auch für grafische Anwenderprogramme wie Browser, Audioplayer, etc.

Für das Programm pactl ist daher logisch, dass es seinen Herren und Meister pulseaudio als sound server benamst, auch wenn dieser letztlich pipewire-pulse ist.

[towo]

Gute Beschreibung, nur was hat das mit der Frage von Ralli zu tun?
Ich kanns zwar auch nicht beantworten, aber in meinem sid(uction) zeigt inxi das an:

Code: Alles auswählen

Audio:     Device-1: Advanced Micro Devices [AMD] Family 17h HD Audio driver: snd_hda_intel
           Device-2: C-Media Audio Adapter (Unitek Y-247A) type: USB driver: cmedia_hs100b,snd-usb-audio,usbhid
           Device-3: WaveRider USB 2.0 Camera type: USB driver: snd-usb-audio,uvcvideo
           Sound Server-1: ALSA v: k5.18.0-rc5-siduction-amd64 running: yes
           Sound Server-2: PipeWire v: 0.3.51 running: yes

[ralli]

Danke @novalix,

vorzügliche Erklärung, aber warum inxi pipewire nicht anzeigt, bleibt unbeantwortet. Weiß unser Sound - und Audioexperte @smutbert vielleicht mehr, oder kann mir versichern, das es kein Konfigurationsfehler meinerseits ist. Oder können Communitymitglieder, die bereits PipeWire erfolgreich zum Laufen gebracht haben, mal überprüfen, was bei Ihnen mit inxi angezeigt wird. Danke!

Viele Grüße ralli

[ralli]

Wen es interessiert, hier sind die Unterschiede zwischen OSS, ALSA, Jack, Pulseaudio und PipeWire auch schön herausgearbeitet:

https://www.linux-bibel-oesterreich.at/ ... .php?t=576

Gruß ralli

[smutbert]

Mein erster Verdacht wäre, dass die inxi-Version einfach nichts von pipewire weiß. Laut changelog [1] werden Pulseaudio, Pipewire, Jack u. s. w. alle gemeinsam seit März 2021 (inxi 3.3.02) unterstützt – in Debians inxi also erst seit ab bullseye-backports und bookworm – wenn du also die normale bullseye-Version hast, dürfte inxi auch pulseaudio nicht erkennen.
Ich kann später einmal die Ausgaben von der bullseye und bullseye-backports-Version vergleichen (bei laufendem Pulseaudio).

edit:
das würde es erklären, mit inxi aus bullseye

Code: Alles auswählen

$ inxi -A
Audio:     Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel 
           Sound Server: ALSA v: k5.16.0-0.bpo.4-amd64

und aus bullseye-backports

Code: Alles auswählen

$ inxi -A
Audio:
  Device-1: Intel Cannon Lake PCH cAVS driver: snd_hda_intel
  Sound Server-1: ALSA v: k5.16.0-0.bpo.4-amd64 running: yes
  Sound Server-2: PulseAudio v: 14.2 running: yes

[1] https://smxi.org/docs/inxi-changelog.htm

[MSfree]

aber warum inxi pipewire nicht anzeigt, bleibt unbeantwortet.

Ich könnte mir vorstellen, daß das mit der Inxi-Version zusammenhängt. Towo nutzt SID, also die ganz heiße Version, deine wird schon eine wenig abgehangen sein und von Pipewire noch gar nichts wissen.

[ralli]

Danke Euch beiden,

geahnt habe ich es auch, aber nicht gewußt. Warum läuft denn mein System weiter, obwohl ich pulseaudio gelöscht habe?

Gruß ralli

[smutbert]

Wie meinst du die Frage jetzt genau – ich meine es wäre ja schlimm, wenn Debian ohne Pulseaudio nicht laufen würde?

[ralli]

Wie meinst du die Frage jetzt genau – ich meine es wäre ja schlimm, wenn Debian ohne Pulseaudio nicht laufen würde?

Hallo @smutbert,

ich habe doch bereits weiter oben geschrieben, das ich mit dem Befehl:

Code: Alles auswählen

apt-get --purge remove pulseaudio

gelöscht habe, sich aber nach einem reboot keine Änderung in der Überprüfung mit pactl Info ergeben hat. Offensichtlich läuft Pulseaudio auf PipeWire. Aber warum? Wenn ich Audacious auf alsa umstelle, funktioniert das nicht.

Ein

Code: Alles auswählen

inxi -U

funktioniert auch nicht, offensichtlich ist die Funktion disabled.

Gruß ralli

[smutbert]

[...] Offensichtlich läuft Pulseaudio auf PipeWire. Aber warum? [...]

"Pulseaudio (on Pipewire...)" ist bereits nicht mehr Pulseaudio sondern sozusagen die Pulseaudio-Schnittstelle, aber bereitgestellt von Pipewire. Pulseaudio selbst läuft also nicht mehr.

Du hast mit diesem Befehl

Code: Alles auswählen

systemctl --user --now enable pipewire pipewire-pulse

gezielt den Teil von pipewire aktiviert, der die Pulseaudio-Schnittstelle zur Verfügung stellt.
Du hättest das auch einfach weglassen können (oder kannst es wieder deaktivieren), aber Progamme, die den Ton über Pulseaudio, nicht aber über pipewire ausgeben können, würden dann nicht mehr funktionieren.

Wenn ich Audacious auf alsa umstelle, funktioniert das nicht.

Wenn du das nackte Alsa verwenden wolltest, dann würdest du dich wahrscheinlich auch um die Konfiguration kümmern müssen, also etwa, dass per default das richtige Audiogerät verwendet wird und auch darum, dass kein anderes Programm, vor allem kein Soundserver wie Pipewire oder Pulseaudio exklusiv das Audiogerät belegt.

Ein

Code: Alles auswählen

inxi -U

funktioniert auch nicht, offensichtlich ist die Funktion disabled.

Ja, das ist klar. Ein Programm, das über das Paketmanagement installiert ist, soll sich ja selbst auch nicht verändern können, auch nicht updaten.
Du müsstest schon die backports in die sources.list aufnehmen und gezielt inxi aus den backports installieren, wenn du das willst.

[ralli]

Vielen Dank @smutbert für Deine engagierte Unterstützung. Ein Blick in die Gnome Systemüberwachung bestätigt das. Es wird kein Prozess pulseaudio mehr angezeigt, aber:

- pipewire

- pipewire-media-session

- pipewire-pulse

Damit dürft ja alles aufgeklärt sein. Ich wollte halt nicht unwissend sterben .... Hauptsache, das es funktioniert. Gefühlt ist die Klangqualität mit audacious und pipewire für mich sehr gut. Und darauf kam es mir ja an.

Gruß ralli