Symptoms & scope
- Crackles appear during CPU load or when a low-latency client starts.
- pw-top ERR increases on a node during audible dropouts.
Relevant environment
PipeWire graphs with ALSA hardware, desktop streams or production clients; low latency reduces scheduling margin.
Recognizable messages (synthetic examples)
pipewire[2140]: [alsa-pcm.c:2862 alsa_recover()] 0x1234: xrun of 3200 usec 154Correlate with audible glitches and pw-top; a trace-level line alone does not identify the slow client.
pipewire[2140]: spa.alsa: hw:0,0p: wrong htimestamps from driver, disablingThis supports a device-timing investigation; it is different from proving CPU overload.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- A processing or scheduling deadline may be missed because of load, too little buffering or a stalled client.
- ALSA timing or timestamp defects can resemble overload; increasing buffering will not repair every driver fault.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Read five graph snapshots as the desktop user while the affected audio is already playing; this does not change graph settings.
pw-top -b -n 5Interpret the result: Compare ERR changes with WAIT/BUSY relative to quantum. Historical ERR alone is weak evidence; the graph driver can count faults propagated from another node.
Check 2
Read timing and recovery messages. Some xrun details are only emitted at trace level, so absence from the ordinary journal is not decisive.
journalctl --user -b -u pipewire.service --no-pager -n 200Interpret the result: Repeated xrun or impossible/wrong timestamp reports provide distinct leads. A device disconnect is a separate transport issue.
Evidence-guided next steps
Increase the affected client’s buffer cautiously
If ERR rises only with a client requesting very small buffers, increase that application’s buffer or latency setting one step and compare the same workload. Prefer its own setting over a global graph override.
Precautions: Greater buffering increases delay, which matters for monitoring and live performance. Record the original rate and buffer before changing them.
Recovery / rollback: Restore the application’s original buffer if errors do not improve or added latency is unacceptable.
Did this solution help you?
Compare load and device-specific timing overrides
If deadline misses correlate with an expensive effect or background workload, disable that one workload temporarily. If the journal instead shows repeatable wrong hardware timestamps, review a narrowly matched ALSA timestamp override with the documented PipeWire properties.
Precautions: Do not disable security services or apply all low-latency tweaks together. Timing overrides need exact device matching and can degrade other hardware.
Recovery / rollback: Re-enable the effect/workload, or remove the single experimental configuration fragment and restart user audio after saving recordings.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- PipeWire: pw-top(1), graph deadlines and ERR counters (project or distribution documentation)
- PipeWire: pipewire-props(7) (project or distribution documentation)
- WirePlumber: ALSA configuration (project or distribution documentation)
- PipeWire ALSA implementation: upstream source snapshot (upstream implementation; behavior can vary by version)