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)
Related hardware and driver context
These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.
Identify hardware locallyInvestigate the gaming failure path
Connect these system observations to Proton, Vulkan and frame-time evidence. A detected GPU or a reset message alone does not establish the cause of a game crash.
Follow the gaming diagnostic questions · Inspect gaming logs locally