You are not logged in.
Hey y'all!
I got a Dell XPS 17 9720 and I got issues with my audio system.
AFAIK, I got pipewire and pipewire-pulse aswell as wireplumber running.
Sometimes my audio just "crashes". It results in crackling audio, but repeating (like when you playback a defective CD), which would indicate to me that something is wrong with e.g. buffers or hardware.
When looking into dmesg, this is the result:
[ 2058.589254] soundwire sdw-master-0-0: Program transport params failed: -22
[ 2058.589265] soundwire sdw-master-0-0: Program params failed: -22
[ 2058.589269] SDW0-Playback: ASoC: error at snd_soc_link_prepare on SDW0-Playback: -22
What I did:
- Started audio playback in brave (chromium) via spotify
- opened pavucontrol
This sometimes happens without anything from my part, as in I'm listening to music via e.g. spotify or trying to playback some youtube video or basically anything that has audio tied to it, and without opening pavucontrol or changing volume etc. it crashes.
Typically, it does so when starting a new song on spotify, so the song has finished playing and now a new playback is started, but it is crackled.
In that case I have to killall -9 pipewire pipewire-pulse and it usually works afterwards, sometimes I need to do it multiple times.
My installation is ofc up to date and has been restarted after the last update.
❯ uname -a
Linux WaveCloud-XPS 6.8.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Tue, 07 May 2024 21:35:54 +0000 x86_64 GNU/Linux
Dont know if it matters, but DE is Hyprland on Wayland, with i915 Intel GPU, an NVIDIA 3050 Mobile and an i7-12700H.
If you need further info let me know.
Thanks!
Last edited by MatKaplinski (2025-06-17 21:04:52)
Offline
This is the relevant part of the pipewire log by running "systemctl --user status pipewire":
Mai 13 11:26:59 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwire,2p: (0 suppressed) snd_pcm_avail after recover: Datenübergabe unterbrochen (broken pipe)
Mai 13 11:27:00 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwirep: snd_pcm_prepare error: Das Argument ist ungültig
Mai 13 11:27:00 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwirep: (0 suppressed) snd_pcm_avail after recover: Die Dateizugriffsnummer ist in schlechter Verfassung
Mai 13 11:27:00 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwirep: recover from error state SETUP
Mai 13 11:27:16 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwire,2p: (44 suppressed) snd_pcm_avail after recover: Datenübergabe unterbrochen (broken pipe)
Mai 13 11:27:18 WaveCloud-XPS pipewire[1564]: spa.alsa: hw:sofsoundwirep: (19 suppressed) snd_pcm_avail after recover: Datenübergabe unterbrochen (broken pipe)
Mai 13 11:27:22 WaveCloud-XPS pipewire[1564]: pw.node: driver alsa_output.pci-0000_00_1f.3-platform-sof_sdw.HiFi__hw_sofsoundwire__sink did not update duration/rate (256/1024 48000/48000)
Offline
I ran into this issue as well, streaming game audio from a remote server via sunshine to a moonlight client on my laptop. What seems to have fixed it for me was increasing the default.clock.min-quantum property in my pipewire conf.
I created a pipewire conf drop in under ~/.config/pipewire/pipewire.conf.d/99-min-quantum.conf
Added...
context.properties = {
default.clock.min-quantum = 512
}
... then rebooted and ran
pw-metadata -n settings
to check that the config change had been picked up.
I'm no expert, but as far as I understand, the quantum refers to the interval in which pipewire tries to process a given chunk of audio. A smaller quantum (I think the default minimum is 32), means that pipewire needs to process an audio chunk in a shorter time. By increasing the minimum quantum to 512, pipewire now has a longer interval in which to process the chunk of audio.
This is important, because if there is an upstream delay in the audio delivery (caused by the game, pipewire, alsa, sunshine) the next chunk of audio might not make it pipewire by the time the processing interval ends. This results in the broken pipe. Pipewire was expecting the next chunk of audio, but didn't get it. But with a longer interval, upstream delays have more time to resolve before the closing of the interval, meaning the pipe does not break.
Take this with a grain of salt. I'm learning too. But this seems to have sorted out my issues. Good luck.
Offline
I will try this out, thanks for your comment on this old post.
May I ask where you went or got the intention to modify this value?
I couldn't find any information for months, and would love to know where you got the idea from
Offline
After testing this using Proton/Wine and playing a game on Steam I had previously experienced audio issues with, this seems to actually resolve my issue.
Thank you very much for finding this out, I will mark the post as solved now.
--
I have to say that I dont understand why this should fix it given your explanation, which makes sense to me.
I am unsure why the pipe (aka the way to transport data to the soundcard) breaks when pipewire/pulse cannot process the audio chunk you mentioned.
I understand that you are no expert, neither am I, but am I wrong in assuming that the game or application provides audio to pipewire, which then sends it to e.g. ALSA for hardware output, where pipewire essentially provides "isolation" between the applications and the hardware audio devices?
If the application isn't fast enough at streaming audio towards pipewire, why does the connection between pipewire and ALSA break? Shouldn't pipewire incase of a buffer underrun then just play "silence" to the audio device or whatever other running applications are playing?
This is probably a question towards the pulseaudio or pipewire developers, if anyone knows why this is, feel free to answer, would love to know.
Offline