Usually crackling is buffer underruns. The sound hardware exhausts the buffered sound before the software can fill the buffer again.
Larger buffer or less stuff slowing down whatever's filling the buffer. I'm typing this with one hand while I eat pizza, but give me a few minutes and I'll give you some suggestions.
EDIT: Okay, took me a few hours instead of a few minutes.
The PULSE_LATENCY_MSEC reference in another comment is a way to increase buffer size at the Pulseaudio level if the program in question is're using pulseaudio (probably yes, as I think that WINE always goes through PulseAudio today).
You can set this persistently and systemwide for PulseAudio in /etc/pulse/daemon.conf
with the default-fragments
and default-fragment-size-msec
.
For PipeWire, the newer system, you can set this at a per-user level using pw-metadata
like so:
https://wiki.debian.org/PipeWire
choppy audio on systems with high load
PipeWire's lower latency compared to PulseAudio can lead to choppy audio on systems with high load.
First view the quantum using the
pw-top
command and then increase the quantum value using this command, until the audio becomes smoother.pw-metadata -n settings 0 clock.force-quantum 2048
Once you find the right quantum value for your situation, you can make the value permanent by creating a config file
~/.config/pipewire/pipewire.conf.d/choppy-under-load.conf
with the following content and restart pipewire related daemons.context.properties = { default.clock.quantum = 2048 default.clock.min-quantum = 2048 }
I don't know how the two typically interact today, unfortunately
most Linux audio systems to date have had some form of emulation of each other, which somewhat complicates matters. When I play back audio from mpv
today using the PipeWire audio output plugin, I see a stream both in pavucontrol
, which is PulseAudio's mixer, and in pw-top
, which is a PipeWire tool. Same thing happened with all of PulseAudio and ALSA and with ALSA and OSS in the past.