PipeWire knistert oder hat Aussetzer unter Last · Linux Fix Lab

Symptome und Geltungsbereich

Knistern tritt bei CPU-Last oder beim Start eines Clients mit geringer Latenz auf.
pw-top ERR steigt während hörbarer Aussetzer an einem Node.

Betroffene Umgebung

PipeWire-Graphen mit ALSA-Hardware, Desktop-Streams oder Produktionsclients; geringe Latenz verringert den Zeitspielraum.

Erkennbare Meldungen (synthetische Beispiele)

pipewire[2140]: [alsa-pcm.c:2862 alsa_recover()] 0x1234: xrun of 3200 usec 154

Mit hörbaren Fehlern und pw-top vergleichen; eine Trace-Zeile allein identifiziert keinen langsamen Client.

pipewire[2140]: spa.alsa: hw:0,0p: wrong htimestamps from driver, disabling

Dies stützt eine Gerätetiming-Untersuchung und beweist keine CPU-Überlast.

Mögliche Ursachen

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

Eine Verarbeitungs- oder Scheduling-Deadline kann durch Last, zu wenig Puffer oder blockierten Client verpasst werden.
ALSA-Timing- oder Zeitstempelfehler können wie Überlast wirken; größere Puffer reparieren nicht jeden Treiberfehler.

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

Während betroffener laufender Wiedergabe als Desktop-Benutzer fünf Graph-Snapshots lesen; Graph-Einstellungen werden nicht verändert.

pw-top -b -n 5

Ergebnis einordnen: ERR-Änderungen und WAIT/BUSY im Verhältnis zum Quantum vergleichen. Alter ERR-Wert allein ist schwach; der Graph-Treiber kann Fehler anderer Nodes mitzählen.

Prüfschritt 2

Timing- und Fehlerbehandlungsmeldungen lesen. Manche xrun-Details erscheinen nur im Trace-Level; Fehlen im normalen Journal ist daher nicht entscheidend.

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

Ergebnis einordnen: Wiederholte xrun- oder unmögliche/falsche Zeitstempelmeldungen liefern unterschiedliche Hinweise. Gerätetrennung ist ein eigenes Transportproblem.

Nächste Schritte nach Befund

Puffer des betroffenen Clients vorsichtig erhöhen

Wenn ERR nur mit einem Client mit sehr kleinen Puffern steigt, dessen Puffer- oder Latenzeinstellung eine Stufe erhöhen und dieselbe Last vergleichen. Eigene Einstellung des Clients einer globalen Graph-Vorgabe vorziehen.

Vorsicht: Größere Puffer erhöhen Verzögerung, relevant bei Monitoring und Live-Einsatz. Ursprüngliche Rate und Puffergröße vorher notieren.

Wiederherstellung / Rücknahme: Ursprünglichen Anwendungspuffer wiederherstellen, wenn Fehler nicht abnehmen oder zusätzliche Latenz unakzeptabel ist.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Last und gerätespezifische Timing-Anpassung vergleichen

Wenn Deadline-Verletzungen mit aufwendigem Effekt oder Hintergrundlast zusammenfallen, nur diese Last vorübergehend abschalten. Zeigt das Journal stattdessen reproduzierbar falsche Hardware-Zeitstempel, einen eng auf das Gerät passenden ALSA-Zeitstempel-Override anhand dokumentierter PipeWire-Eigenschaften prüfen.

Vorsicht: Keine Sicherheitsdienste abschalten oder alle Low-Latency-Tricks gleichzeitig setzen. Timing-Anpassungen brauchen genaue Gerätezuordnung und können andere Hardware verschlechtern.

Wiederherstellung / Rücknahme: Effekt beziehungsweise Last wieder einschalten oder das einzelne experimentelle Konfigurationsfragment entfernen und Benutzer-Audio nach Speichern von Aufnahmen neu starten.