Kein Ton unter Linux? PipeWire, WirePlumber, ALSA & Bluetooth systematisch prüfen

Hier anfangen: die fehlerhafte Ebene finden

Meldet wpctl status den Fehler Could not connect to PipeWire, starte mit dem Verbindungspfad. Listet es deine Lautsprecher, beginne bei Routing und Stummschaltung. Den Soundserver vor dieser Unterscheidung neu zu installieren, kann aus einem kleinen Routingproblem eine Paketmigration machen.

Öffne über das Anwendungsmenü deines Desktops ein Terminal. Führe jeden Befehl einzeln als der Benutzer aus, dessen Ton nicht funktioniert. Ein vorangestelltes $ wäre nur ein Prompt und gehört nicht zum Befehl; unsere Beispiele lassen es weg. Ergänze bei wpctl oder systemctl --user niemals einfach sudo: Root hat eine andere Sitzung. Ein nicht installierter Befehl bedeutet ein fehlendes Werkzeug, keine verschwundene Soundkarte.

Wie Linux-Audio tatsächlich beim Lautsprecher ankommt

Eine erkannte Karte ist erst der Anfang. Der Kerneltreiber stellt ALSA-Regler sowie Wiedergabe- und Aufnahmeinterfaces bereit. Eine Anwendung braucht eine passende Schnittstelle, einen erreichbaren Server, eine gewählte Route und eine Gerätekonfiguration, die die Hardware verarbeiten kann. Eine erfolgreiche ALSA-Kartenliste beweist die Registrierung auf dieser Ebene. Sie beweist nicht, dass der Browser einen Stream zu dieser Karte schickt.

PipeWire betreibt den Multimedia-Graphen. Anwendungen können seine native API oder Kompatibilitätsbibliotheken nutzen. Clients des PulseAudio-Protokolls erreichen auf einem PipeWire-Desktop normalerweise pipewire-pulse. ALSA-Anwendungen können über das ALSA-Plugin der Distribution zu PipeWire gelangen; ein absichtlich geöffnetes hw:-Gerät greift hingegen direkt auf ALSA zu und kann mit dem Server um das Gerät konkurrieren. JACK-Anwendungen können PipeWires JACK-Implementierung verwenden, wenn die entsprechenden Bibliotheken ausgewählt sind. Ein separat laufender JACK-Server ist ein anderer Aufbau.

WirePlumber liefert die Regeln: welche Geräte sichtbar werden, welche Profile aktiv sind, welche Routen wiederhergestellt und welche Streams verbunden werden. Er lädt Hardware-Monitore und steuert Graphobjekte. Er ist keine serielle Audiotransportstufe zwischen PipeWire und ALSA. Bluetooth nimmt den Weg über BlueZ und Funk, statt als lokale ALSA-Karte aufzutreten. Grundlagen: PipeWire-Überblick und WirePlumber-Komponenten.

Erst lesen, dann reparieren

Nutze für Vergleiche eine leise, bekannte lokale Audiodatei. Prüfe eingeschalteten Verstärker, richtige Buchse und niedrige physische Lautstärke. Eine stumme Anwendung und ein schlafender Digitalempfänger können aus völlig verschiedenen Gründen dieselbe Stille erzeugen. Notiere, was unmittelbar vor dem Fehler passiert ist: Update, Docking, Headset-Anruf, Resume oder Monitorwechsel.

Die folgenden Befehle beobachten. Sie wenden keine Reparatur an. Ein Client kann beim Verbinden normale Socket-Aktivierung auslösen; „nur lesend“ heißt hier, dass er keine Konfigurationsänderung anfordert. Die Referenz nennt Rechte, erwartete Befunde und Grenzen. Ein gemeldeter Zustand ist ein Hinweis, kein Urteil.

wpctl status

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

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

Ordne Namen in der Statusliste dem tatsächlichen Gerät zu und beachte die Standardmarkierung. Lies im Journal den ersten aussagekräftigen Fehler zum passenden Zeitpunkt. Eine Warnung über eine ungenutzte optionale Komponente ist kein gescheiterter Audiograph. Ein Rückgabewert ungleich null bei systemctl status ist für inaktive oder fehlende Units erwartbar; lies den angezeigten Zustand.

„Could not connect“: Server, Socket oder Kompatibilitätsbrücke?

Die Meldung belegt, dass dieser Client den gewählten PipeWire-Server nicht erreicht hat. Warum, steht damit noch nicht fest. Gestoppter Server, falsches Runtime-Verzeichnis, beabsichtigter Remote-Override, fehlendes Paket oder anderer Benutzer kommen infrage. WirePlumber kann ebenfalls scheitern; ein gesunder PipeWire-Server kann aber Clients annehmen, obwohl seine Policy fehlt. Trenne diese Fehler.

Prüfe Dienst und Socket. Bei Socket-Aktivierung kann ein inaktiver Dienst bis zur ersten Clientverbindung normal sein. Ein aktiv lauschender Socket belegt Aktivierung, keine funktionierende Lautsprecherroute. Ist eine Unit maskiert, kläre vor der Aufhebung, wer sie warum maskiert hat. Aktiviere nicht versuchsweise eigenständiges PulseAudio und seinen PipeWire-Ersatz gleichzeitig.

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

pactl info

pactl info identifiziert den erreichbaren Server des PulseAudio-Protokolls. Ein Name mit „on PipeWire“ kennzeichnet die Kompatibilitätsbrücke. Ein eigenständiges PulseAudio-System muss überhaupt kein wpctl anbieten. Wenn wpctl funktioniert, pactl aber keine Verbindung bekommt, untersuche pipewire-pulse, dessen Socket und einen möglichen PULSE_SERVER-Override. Native und PulseAudio-Anwendungen können unterschiedlich scheitern.

systemctl --user start wireplumber.service

Bei „Device or resource busy“ den Besitzer ermitteln, statt alle Audioprozesse zu töten. Dass PipeWire ein PCM geöffnet hält, ist oft normal. Ein zweiter direkter ALSA-Client oder anderer Server ist ein konkreterer Hinweis. Der gemeinsame ALSA-Besitzerfall enthält die lesende Besitzerprüfung und Vorsichtsmaßnahmen.

Die Benutzersitzung zählt, besonders bei minimalen Desktops

Prüfe innerhalb der betroffenen lokalen Desktop-Anmeldung. Root-Terminal, su, SSH oder Container sind nicht automatisch dieselbe Audioumgebung. Bei üblicher systemd/PAM-Anmeldung gehört das Runtime-Verzeichnis dem Benutzer und liegt häufig unter /run/user/<UID>. PipeWire findet seinen Socket über Runtime- und Remote-Variablen. Benutzermanager und D-Bus-Sitzung gehören zur Infrastruktur; ein unerreichbarer Benutzerbus ist aber ein anderer Fehler als eine gescheiterte Audiogeräteerkennung.

id -u

printenv XDG_RUNTIME_DIR PIPEWIRE_RUNTIME_DIR PIPEWIRE_REMOTE PULSE_SERVER

Erfinde kein XDG_RUNTIME_DIR, übernimm kein fremdes Runtime-Verzeichnis und verdrahte nicht UID 1000. Vergleiche zuerst ein frisch aus dem Desktop geöffnetes Terminal. Exportiert deine eigene Startdatei einen veralteten Remote, sichere genau diese Datei vor dem Entfernen dieses einen Eintrags; mit der Sicherung machst du es rückgängig. Bei XMonad/dwm/startx zählt die unterstützte Sitzungseinrichtung deiner Distribution. Übernimm nicht blind die Umgebung eines anderen Desktops. X11 und Wayland ersetzen weder ALSA noch PipeWire; Sitzungsstart, Rechte und Portale können trotzdem abweichen. Siehe pam_systemd.

PipeWire läuft, aber es kommt nichts Brauchbares an

Arbeite vom Graphen zum Kabel. Ist der gewünschte Ausgang vorhanden? Ist er Standard? Spielt die App tatsächlich dorthin? Ist er stumm? Stellt das gewählte Kartenprofil den benötigten Port bereit? Ein frisch angeschlossener Monitor kann zum Wiedergabeziel werden, obwohl deine Lautsprecher weiter an der Analogkarte hängen.

wpctl get-volume @DEFAULT_AUDIO_SINK@

pactl list cards

Der Standard gilt für Streams mit automatisch gewähltem Ziel; bestehende Streams können ein anwendungsspezifisches Ziel behalten. Verschiebe in den Desktop-Audioeinstellungen oder pavucontrol den tatsächlich spielenden Stream. Notiere das alte Ziel und stelle es bei erfolglosem Vergleich wieder her. Ebenso altes Kartenprofil und Port festhalten: Profilwechsel können Endpunkte entfernen und neu erzeugen sowie Wiedergabe und Aufnahme unterbrechen.

wpctl set-mute @DEFAULT_AUDIO_SINK@ 0

Für die Standardwahl per Terminal nimmt wpctl set-default ID eine Ausgangs- oder Eingangs-Node-ID aus dem aktuellen Status, keine Karten-ID. Alten Standard vorher notieren; dessen aktuelle Node-ID wieder zu setzen stellt die vorige Auswahl her. Bei Hardware-Mixerproblemen öffnet alsamixer mit F6 die Kartenauswahl, F3 Wiedergabe und F4 Aufnahme. Den Mixer zu öffnen ist kein Reset; einen Schalter zu ändern ist eine Maßnahme. Ausgangswerte notieren und nur den passenden Wiedergaberegler ändern.

WirePlumber 0.4 und 0.5: Konfigurationsformate nicht mischen

Prüfe wireplumber --version, bevor du eine Regel aus einem Suchtreffer übernimmst. WirePlumber 0.5 wechselte zur SPA-JSON-Konfiguration und migriert alte Lua-Konfiguration nicht automatisch. Eine vollständig kopierte wireplumber.conf kann nach einem Upgrade außerdem ein altes Komponentenlayout festhalten. Upstream empfiehlt Fragmente statt einer veraltenden privaten Kopie der Herstellerdatei.

Unter 0.5 liegen Benutzerfragmente normalerweise in ~/.config/wireplumber/wireplumber.conf.d/, entsprechend unter einem eigenen XDG_CONFIG_HOME. Bei 0.4 gehören Anleitungen für main.lua.d/bluetooth.lua.d zu einem anderen Format. Lua nach .conf umzubenennen ist keine Migration. Nutze den Upstream-Migrationsleitfaden und die Fragmentdokumentation.

systemctl --user restart wireplumber.service

Dummy Output und fehlende ALSA-Hardware

„Dummy Output“ sagt, dass in diesem Serverkontext kein nutzbarer Wiedergabeausgang vorhanden ist. Trenne vier Befunde: keine ALSA-Karte; Karte ohne benötigtes PCM; PCM ohne PipeWire-Node; Node durch Profil-/Routenwahl verborgen. Bluetooth läuft über einen anderen Hardware-Monitor und wird nicht in aplay -l erwartet.

cat /proc/asound/cards

aplay -l

lspci -nnk

journalctl -k -b --no-pager -n 350

HD-Audio-Controller und Codecs sind unterschiedliche Bausteine; snd_hda_intel bedeutet nicht „nur Intel-Hardware“. Ein PCI-Eintrag beweist keinen initialisierten Codec. Bei SOF-Systemen ist eine konkret fehlende Firmware-/Topologiedatei im Journal hilfreich: Exakten Dateinamen und Plattform den Firmwarepaketen deiner Distribution zuordnen. Keine DSP-Treiberwechsel, probe_mask- oder model=-Optionen eines anderen Laptops erraten.

Eine Kernelwarnung über den Wechsel auf Polling kann überlebbar sein; wiederholte Probe-Fehler samt fehlender Karte sind etwas anderes. Verschwand die Karte nach einem Update, vergleiche einen bereits installierten, zuvor funktionierenden Kernel. Behalte aktuelle und alte Bootoptionen für den Rückweg. Die HD-Audio-Hinweise des Kernels erklären, warum gerätespezifische Sonderregeln Befunde brauchen.

Mikrofone: Eingang, Aufnahmeweg und App-Freigabe

Wähle die physische Quelle statt „Monitor of …“. Prüfe Laptop-Privatschalter oder Headset-Mute, bevor du Verstärkung erhöhst. Kontrolliere die Quellenwahl in der App; ein anderer Systemstandard ersetzt nicht zwingend eine gespeicherte App-Auswahl. Bewegter Desktop-Pegel bei stillem App-Pegel deutet auf eine andere Ebene als ein überall stummer Eingang.

arecord -l

wpctl get-volume @DEFAULT_AUDIO_SOURCE@

arecord -l listet Aufnahmehardware ohne Aufnahme. Es beweist kein Mikrofonsignal. Für einen bewussten Aufnahmetest den Desktop-Rekorder mit klar gewählter Quelle nutzen, nur eigene Testsprache aufnehmen und die Datei anschließend im Dateimanager löschen. Systemfreigabe und Browserfreigabe je Website getrennt prüfen. Die ALSA-Aufnahmeanleitung dokumentiert Capture-Schalter und Grenzen von Standardgerätetests.

Warum das Bluetooth-Headset plötzlich wie ein Telefon klingt

Klassisches Bluetooth-A2DP ist gewöhnlich der hochwertige Wiedergabeweg. HSP/HFP bieten bidirektionales Headset-Audio; die Qualität hängt von Codec und Hardware ab. Das Öffnen des Headset-Mikrofons kann deshalb den Wiedergabeklang ändern. Oft ist das ein Profilwechsel, keine kaputte Samplerate oder zu schwache CPU. Ein separates USB-/Analogmikrofon kann ermöglichen, klassische A2DP-Wiedergabe beizubehalten.

Beobachte das Profil beim Starten und Stoppen der Aufnahme in der Anruf-App. Schließe den Mikrofonstream, bevor du wieder A2DP vergleichst. Vorigen App-Eingang und Headset-Profil notieren und für den Rückweg wiederherstellen. Nicht sämtliche Codecs abschalten oder global ein Profil erzwingen, bevor der Wechsel belegt ist. LE Audio ist eine eigene Fähigkeitsfrage: Controller, Headset, BlueZ, PipeWire und Distributionskonfiguration müssen zusammenpassen.

Bei ganz fehlender Verbindung das gekoppelte Gerät in den Bluetooth-Einstellungen untersuchen und eine belegte Verbindung zu einem anderen Host ausschließen. BlueZ „Connected“ beweist keinen PipeWire-Ausgang. Danach folgen Bluetooth-Plugin-Pakete und aktive Sitzungszuordnung. WirePlumbers Bluetooth-Konfiguration erklärt Seat-Monitoring; die dokumentierten Einstellungen erklären automatische Profilwechsel. Seat-Monitoring nicht abschalten, um eine falsche Anmeldesitzung zu umgehen.

Nur eine App, Steam, OBS, Discord oder der Browser ist stumm

Funktioniert eine andere App am selben Ausgang, behalte diesen funktionierenden Vergleich. Prüfe Mute, Backend, Ausgabegerät und aktiven Stream der betroffenen App. Ein bewegter OBS-Quellpegel beweist nicht, dass die Quelle der gewählten Aufnahme- oder Streamspur zugeordnet ist. Beim Browser sind Tab-/Website-Stummschaltung und Mikrofonfreigabe getrennt. Bei Steam/Proton zuerst prüfen, ob das Spiel einen Stream erzeugt, bevor globale Servereinstellungen geändert oder Präfixe gelöscht werden.

pactl list sink-inputs

flatpak info --show-permissions APP_ID

Für Flatpak APP_ID durch die installierte Kennung ersetzen. Seine pulseaudio-Socketfreigabe betrifft Audiozugriff auch bei PipeWire als Hostserver. Fehlende Freigabe, App-Override und fehlerhafte Host-Kompatibilitätsbrücke sind unterschiedliche Hinweise. Zuerst untersuchen; eine begründete Änderung über die vorgesehenen Freigaberegler vornehmen und vorige Freigabe für den Rückweg notieren. Keine pauschalen Dateisystem-/Geräterechte vergeben. Siehe Flatpak-Rechtereferenz.

Knacken, Puffer und XRUNs: erst korrelieren, dann tunen

Der Graph verarbeitet Audio in Blöcken. Quantum geteilt durch Samplerate ergibt die nominelle Blockdauer: 256 Frames bei 48 kHz sind etwa 5,33 ms, nicht die gesamte Mikrofon-Lautsprecher-Latenz. Kleinere Blöcke reduzieren einen Verzögerungsanteil, lassen aber weniger Zeit bis zur Deadline. Gerätepuffer, Wandler, Resampling, Transport und Anwendung tragen weitere Latenz bei.

pw-top -b -n 5

Beobachte in pw-top QUANT/RATE, WAIT, BUSY und Änderungen von ERR während des hörbaren Fehlers. ERR zählt XRUNs und andere Fehler. Eine aufgelaufene Zahl älterer Wiedergabe beweist keinen aktuellen Schedulingfehler. Driver- und Follower-Nodes erfassen unterschiedliche Zeitanteile; ein Driver kann einen anderswo verursachten Graphfehler mitzählen. Lies die Spaltendefinitionen, statt aus einer großen Zahl eine Diagnose abzuleiten.

Vergleiche dieselbe lokale Datei im Leerlauf und unter der auslösenden Last, danach einen anderen Ausgang. USB-Resets verlangen Transport-/Strom-/Kabelprüfung, kein größeres Graph-Quantum. Bluetooth-Paketverlust und Clipping können ähnlich klingen. Bietet eine professionelle App eine eigene Puffereinstellung, Ausgangswert notieren, einen Schritt ändern und vergleichen; bei Wirkungslosigkeit zurückstellen. Realtime-Unterstützung und Distributionslimits vor Prioritätsänderungen prüfen. Nicht den ganzen Server als Root starten.

pw-cli ls Node

pw-dump

Meine fehlenden zwei Sekunden: S/PDIF-Stille hat mehrere Ursachen

Mein altes digitales S/PDIF-System verschluckte nach einer Pause, beim Spulen im Video oder nach kurzer Stille regelmäßig ungefähr die ersten zwei Sekunden. Kurze Benachrichtigungstöne konnten vollständig verschwinden. Daraus entstand mein eigenes spdif-fix. Inzwischen nutze ich am PC kein S/PDIF mehr. Die wichtige Unterscheidung bleibt: Gleichmäßige Wiedergabeverzögerung und verlorener Anfang nach Stille sind unterschiedliche Fehlerbilder.

Mehrere Übergänge kommen infrage. Die App kann ihren Stream stoppen oder trennen. Die Policy kann nach Leerlauf einen Node suspendieren und dessen ALSA-Gerät schließen. Ein Digitalempfänger kann seinerseits Träger-/Formatsynchronisation verlieren oder digitale Stille stummschalten. Das Servergerät offenzuhalten adressiert einen dieser Übergänge; es garantiert keinen dauerhaften Lock jedes externen Verstärkers. Das sind vergleichbare Hypothesen, keine nachträgliche Messung meines Empfängers.

pactl list sinks short

Vergleiche genau diesen Ausgang während Wiedergabe und nach dem stillen Intervall. Wird er SUSPENDED, ist ein gerätespezifischer Policy-Test sinnvoll. Bleibt er aktiv und der Empfänger verliert seine Signalanzeige, auch Empfänger und Transport untersuchen. Ein laufender Stream voller Nullen kann trotzdem als Stille gelten. Umgekehrt ist ein Keepalive mit Nichtnullsignal nicht garantiert unhörbar und kann Mixing, Strombedarf oder Passthrough beeinflussen.

Ein eng begrenztes Beispiel für WirePlumber 0.5

Zuerst wireplumber --version prüfen. Das Beispiel nutzt das dokumentierte 0.5-Konfigurationsformat. Aus wpctl status die aktuelle ID deines Digitalausgangs wählen, dann über Inspect dessen exakten node.name ermitteln. Platzhalter unten durch diesen Wert ersetzen; keinen Wildcard für alle Ausgänge verwenden. Eine ID ist kein dauerhafter Name.

wpctl inspect ID

monitor.alsa.rules = [
  {
    matches = [
      { node.name = "REPLACE_WITH_EXACT_DIGITAL_SINK_NODE_NAME" }
    ]
    actions = {
      update-props = {
        session.suspend-timeout-seconds = 0
      }
    }
  }
]

Unter ${XDG_CONFIG_HOME:-$HOME/.config}/wireplumber/wireplumber.conf.d/51-audio-rescue-spdif.conf speichern. Wenn keine Aufnahme davon abhängt, nur WirePlumber mit dem obigen Neustartbefehl neu starten. Journal und passenden Ausgang erneut prüfen, danach Pause-/Spultest mit ansonsten gleichen Einstellungen wiederholen. Upstream dokumentiert: Null deaktiviert Node-Suspend und hält das ALSA-Gerät belegt. Das kann Strombedarf erhöhen und andere direkte Clients am Gerätezugriff hindern. Siehe ALSA-Node-Regeln.

Wie mir mein S/PDIF-Fix damals geholfen hat

Auf meinem damaligen S/PDIF-System ging die Soundkarte immer wieder in den Stromsparmodus, obwohl ich ihn bereits ausgeschaltet hatte. Nach einer Pause oder beim Spulen fehlte dadurch regelmäßig der Anfang des Tons. Mein S/PDIF-Fix half mir genau bei diesem Problem: Er spielte einen kontinuierlichen, für mich nicht hörbaren Dauerton ab. Dadurch blieb die Soundkarte aktiv, statt erneut in den Stromsparmodus zu wechseln. Diesen Workaround nutzte ich bis zu meinem Wechsel auf die analoge Verbindung über Cinch.

Die Keepalive-Wiedergabe steckt im Skript soundfixforautostart.sh, das einen sehr leisen SoX-Ton startet. Für mein damaliges System war das eine praktische Lösung für ein ausgesprochen lästiges Alltagsproblem. Wie ich den Fix eingesetzt habe, beschreibe ich ausführlicher im S/PDIF-Artikel.

HDMI und DisplayPort: Ein PCM ist noch kein angeschlossener Empfänger

GPU-Audio kann registriert sein, obwohl Monitor, Adapter oder Empfänger keine nutzbaren Audiofähigkeiten melden. Tatsächlichen Displayeingang, Kabel, Empfängerstrom und überhaupt vorhandene Audioausgabe des Bildschirms prüfen. Manche Adapter übertragen das gewünschte Format nicht. ELD beschreibt gemeldete Audiofähigkeiten des angeschlossenen Empfängers; Datei für tatsächliche Karte und Anschluss wählen, nicht den ersten Eintrag voraussetzen.

cat /proc/asound/card0/eld#0.0

monitor_present, eld_valid, Monitorname und Audio-Deskriptoren gemeinsam lesen. Ein gültiger Eintrag beweist weder richtiges Profil noch App-Route. Scheitert Erkennung erst nach Docking oder Schlaf, ELD und Graph vor und nach bewusstem Neuverbinden vergleichen; das unterbricht Bild und Audio. Anschließend Originalanschluss und Profil wiederherstellen. Kein dauerhaft erzwungenes Profil über eine instabile physische Verbindung legen.

USB-DACs: Transport, Formate und Clocks

lsusb

Zuerst USB-Erkennung prüfen, dann ALSA-Registrierung der Audiointerfaces, dann erwartete PipeWire-Nodes. Vor Schuldzuweisung an den Soundserver einen direkten Port und ein bekannt gutes Kabel testen. Originalverbindung dokumentieren und für den Rückweg wiederherstellen; Portwechsel kann Geräteidentität oder gespeicherte Routen verändern.

Bei Raten-/Clock-Fehlern listet die passende /proc/asound/cardN/streamM-Datei unterstützte Formate. Beide Indizes durch die Werte deines Geräts ersetzen. Gemeldete Raten belegen keinen externen Clock-Lock. Angeforderte Rate und Kanäle der App mit dem richtigen Wiedergabe-/Aufnahmeinterface vergleichen. Trennung/Reset im Kerneljournal betrifft eine andere Ebene als steigende Deadline-Fehler im Graphen.

5.1 / 7.1, Kanalzuordnung und codiertes Passthrough

Kanalzahl, Kanalreihenfolge und Codierung sind getrennte Fragen. Analoges Surround benötigt richtiges Profil, Buchsen und Verkabelung. HDMI-Mehrkanal-PCM hängt von Empfängerfähigkeiten ab. Klassisches S/PDIF transportiert üblicherweise Stereo-PCM oder passendes komprimiertes Surround; „7.1“ auszuwählen schafft keine Bandbreite für beliebiges Mehrkanal-PCM. Auch Player-Passthrough braucht einen Codec, den der Empfänger decodieren kann.

Zuerst Stereo-PCM ohne Keepalive vergleichen, dann bekannte Kanalansage am vorgesehenen Profil leise testen. Ursprüngliches Profil, Player-Passthrough und etwaige Kanalzuordnung vor gezieltem Test notieren und bei Misserfolg wiederherstellen. Nicht dieselbe erzwungene audio.position auf jede Karte anwenden. Der gemeinsame Digitalprofil-Fall erklärt IEC958-Regler und Vorsichtsmaßnahmen.

Nach System-Suspend: vorher und nachher vergleichen

Ein Systemschlaf ist mehr als ein untätiger Wiedergabe-Node. USB kann sich neu verbinden, GPU-Empfängerinformationen können wechseln und Controller-/Firmware-Resume kann scheitern. Vor dem Schlaf Graph sichern, nach Resume Gerätenamen, Profile und Routen vergleichen. IDs können neu vergeben werden. Kernel- und betroffenes Benutzerjournal um diesen Zeitpunkt lesen, bevor ein Dienstneustart den nützlichsten Zustand verändert.

Verschwindet Hardware aus ALSA, kann eine Routingänderung ihre Registrierung nicht wiederherstellen. Bleibt sie vorhanden und die App zeigt auf einen alten Endpunkt, diese Route korrigieren. Bleiben beide vorhanden, Zeitstempel und ersten Fehler für einen gezielten Treiber-/Serverbericht sichern. Einen zuvor funktionierenden installierten Kernel nur bei Hinweisen auf Regression vergleichen; funktionierende Bootoption behalten.

Debian, Ubuntu, Fedora und Arch: Paketnamen nicht austauschen

Debian 13 bündelt im Metapaket pipewire-audio den empfohlenen Desktop-Satz samt WirePlumber, PulseAudio-Brücke, ALSA-Anbindung und Bluetooth-Plugin. Das installierte Paket pipewire allein belegt diese Schnittstellen nicht. Ubuntu-Versionen können verschiedene WirePlumber-Zweige ausliefern: Die 24.04-Paketfamilie nutzt 0.4-Bibliotheken, das 26.10-Manifest listet einen 0.5-Daemon. Installierte Version prüfen, nicht vom Artikeldatum ableiten.

Fedora nennt das PulseAudio-Ersatzpaket pipewire-pulseaudio; Debians Paketname gilt dort nicht automatisch. Archs PipeWire-Referenz beschreibt getrennte Kompatibilitätspakete und ein konsistentes Systemupgrade. Pakettransaktion samt Entfernungen vorab ansehen. Hier steht bewusst kein Neuinstallationsbefehl als universelle Reparatur. Ohne systemd den vorgesehenen Dienstmanager verwenden; die Unterscheidung zwischen Graph und Hardware bleibt gültig.

Fragen, die bei der Diagnose immer wieder kommen

Soll ich wpctl mit sudo ausführen?

Nein. Nutze das betroffene Desktop-Konto. Ein Root-Prozess kann mit falscher Runtime und Sitzung das eigentliche Problem verdecken.

Bedeutet SUSPENDED, dass mein Sound kaputt ist?

Nein. Häufig ist das normales Energiesparen im Leerlauf. Übergang und Fehlerbild am konkreten Gerät vergleichen, bevor du eine gezielte Regel testest.

Kann ich alle Audiokonfigurationen löschen und neu anfangen?

Nicht als ersten Schritt. Journal lesen, Konfiguration sichern und ein verdächtiges Fragment isolieren. Vollständiger Reset vernichtet Befunde und andere Einstellungen.

Repariert ein anderer Standard jede Anwendung?

Nicht zwingend. Ein vorhandener Stream oder gespeicherter App-Wert kann ein anderes Ziel behalten. Aktiven Stream mitprüfen.

Hilft ein größerer Puffer gegen jedes Knacken?

Nein. Deadline-Fehler, Clipping, Transportverlust und Clock-Fehler benötigen unterschiedliche Befunde. Zähleränderungen während des hörbaren Fehlers vergleichen.

Was bei unklarem Ergebnis erhalten bleiben sollte

Distribution, installierte PipeWire-/WirePlumber-Versionen, genaues Gerätemodell samt USB-/PCI-Kennung, Auslöser, ersten relevanten Fehler und einen kontrollierten Vorher-nachher-Vergleich sichern. Rohe Logs lokal behalten; Benutzernamen, Pfade, Hostnamen und Geräteadressen vor bewusster Weitergabe ausgewählter Zeilen bereinigen. Der Assistent hat kein Log-Uploadfeld und trifft keine Reparaturentscheidung für dich.

Alle zwölf vorhandenen Audiofälle des Linux Fix Lab bleiben die gemeinsame Quelle für deren ausführliche Diagnosen, Vorsicht und Rückwege. Der Assistent ergänzt Navigation und neue Fehlerbildunterscheidungen und bettet die aktuellen gemeinsamen Datensätze beim Build ein. Alle Audiofälle durchsuchen oder den Linux Hardware Explorer nutzen, wenn die Gerätekennung fehlt. Journalgrundlagen erklärt der journalctl-Ratgeber.

Quellen und Prüfung

Dokumentationsabgleich: 27. Oktober 2026. Die abgerufenen Upstream-Seiten kennzeichnen die PipeWire-Dokumentation als 1.6.10 und die WirePlumber-Dokumentation als 0.5.18. Das behauptet nicht, dass jede Distribution diese Versionen ausliefert. Für verfügbare Optionen zählt das installierte Handbuch. Die Browseranwendung wird als Software getestet; ein erfolgreicher Browsertest ist kein Hörtest an Audiohardware.

1. PipeWire: server, runtime and clients
2. WirePlumber: wpctl
3. WirePlumber: components and profiles
4. WirePlumber: ALSA rules and node suspend
5. WirePlumber: migration 0.4 → 0.5
6. WirePlumber: configuration fragments
7. WirePlumber: Bluetooth monitor
8. WirePlumber: profile switching settings
9. PipeWire: pw-top column definitions
10. PipeWire: object / device properties
11. PipeWire: pw-cli
12. PipeWire: pw-dump
13. systemd: systemctl
14. systemd: login and runtime directories
15. Linux kernel: HD-Audio notes
16. ALSA: sound card testing
17. Flatpak: sandbox permissions
18. Ubuntu: pactl manual
19. Debian 13: pipewire-audio dependencies
20. Ubuntu 24.04: WirePlumber package family
21. Ubuntu 26.10: WirePlumber package
22. Fedora: pipewire-pulseaudio package
23. SPDIF-Fix: reviewed source