Audio, ALSA und PipeWire

PipeWire oder Benutzer-Session-Manager startet nicht

Gestoppten Benutzer-Audiodienst von fehlender Hardware trennen und Konfigurations- oder Paketfehler vor wiederholten Session-Neustarts auswerten.

Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • wpctl kann sich nicht mit PipeWire verbinden.
  • PipeWire- oder WirePlumber-Benutzer-Units sind fehlgeschlagen oder fehlen.

Betroffene Umgebung

Desktop-Sitzungen mit PipeWire, WirePlumber und optional pipewire-pulse; systemd-Benutzerbefehle ohne sudo ausführen.

Erkennbare Meldungen (synthetische Beispiele)
pipewire[2140]: could not load mandatory module "libpipewire-module-rt": No such file or directory

Genannte Anpassung und Paketinhalt prüfen; dies ist ein Start-/Konfigurationshinweis, keine Soundkarten-Defektdiagnose.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Fehlerhafte lokale Konfiguration oder ein fehlendes Pflichtmodul kann den Daemon stoppen.
  • Fehlende Benutzer-Units, nicht zusammenpassende Paketteile oder defekte Login-Sitzung können Socket- und Dienststart verhindern.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Audio-Benutzer-Unit-Zustand im betroffenen Desktop-Konto ohne sudo lesen. Manche Units sind auf der jeweiligen Distribution optional.

systemctl --user status pipewire.service pipewire.socket wireplumber.service pipewire-pulse.service --no-pager

Ergebnis einordnen: Eine fehlgeschlagene Unit benötigt ihren ersten Fehler; Unit not found kann fehlendes Paket oder distributionsspezifischen Namen bedeuten. Laufende Dienste beweisen keine vorhandenen Routen.

Prüfschritt 2

Startfehler und Konfigurationskontext dieses Kontos lesen; kein Dienst wird neu gestartet.

journalctl --user -b -u pipewire.service -u wireplumber.service -u pipewire-pulse.service --no-pager -n 200

Ergebnis einordnen: Ein genanntes fehlendes Modul verweist auf Paketierung oder Konfiguration; D-Bus-/Runtime-Fehler auf die Sitzungseinrichtung. Den ersten Fehler sichern, bevor reset-failed ihn weniger sichtbar macht.

Nächste Schritte nach Befund

Bestätigt fehlerhafte lokale Anpassung isolieren

Wenn der erste Fehler eine Benutzeranpassung nennt, diese Datei sichern und nur die betroffene Anpassung vorübergehend aus dem aktiven Konfigurationsverzeichnis verschieben. Nach Speichern aktiver Arbeit den betroffenen Benutzer-Audiodienst neu starten und den Start vergleichen.

Vorsicht: Audio-Neustart unterbricht Gespräche und Aufnahmen. Nicht die gesamte Benutzerkonfiguration entfernen oder Distributionsvorgaben durch eine alte vollständige Konfigurationsdatei ersetzen.

Wiederherstellung / Rücknahme: Gesicherte Datei zurücklegen und dieselbe Benutzer-Unit neu starten, wenn die Anpassung nicht verantwortlich war; Syntax vor erneutem Aktivieren korrigieren.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Konsistenten Distributions-Audiostack herstellen

Wenn ein benötigtes Modul oder eine Service-Unit fehlt, zusammenpassende PipeWire-/WirePlumber-Komponenten der Distribution installieren oder reparieren. Nur den vorgesehenen Session-Manager aktivieren und danach die betroffene Desktop-Sitzung ab- und anmelden.

Vorsicht: Dienstvorgaben der Distribution befolgen, statt einen Root-PipeWire-Server oder zwei Session-Manager für denselben Graphen zu starten.

Wiederherstellung / Rücknahme: Bei Regression anderer Audiofunktionen mit dokumentierter Pakettransaktion oder vorheriger Systemgeneration den bisherigen Stack wiederherstellen.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.