Hello everyone,
I managed to resolve the problem but decided to post it anyway with the steps I took to examine and resolve the problem, in case it can help someone else in the future.
Symptoms
Since a few days I was experiencing some horribly chopped audio. After running for a while (like watching a youtube video for a few minutes), it could disappear on its own, until I paused the video and then restart it, at which point it again took a few minutes to stabilize.
Setup
I am using pipewire-pulse and pipewire-jack. I have no pulseaudio or other sound servers installed.
This is the output of inxi -Aaz
Audio:
Device-1: Intel Alder Lake PCH-P High Definition Audio
vendor: Tongfang Hongkong driver: snd_hda_intel v: kernel
alternate: snd_sof_pci_intel_tgl bus-ID: 00:1f.3 chip-ID: 8086:51c8
class-ID: 0403
Device-2: NVIDIA GA106 High Definition Audio vendor: Tongfang Hongkong
driver: snd_hda_intel v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 8
link-max: gen: 4 speed: 16 GT/s lanes: 16 bus-ID: 01:00.1
chip-ID: 10de:228e class-ID: 0403
Device-3: Roland INTEGRA-7 driver: snd-usb-audio type: USB rev: 1.1
speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 3-1:2 chip-ID: 0582:015c
class-ID: 0103
Device-4: BEHRINGER GmbH UMC1820 driver: snd-usb-audio type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 3-3:4 chip-ID: 1397:0503
class-ID: fe01 serial:
API: ALSA v: k6.4.5-arch1-1 status: kernel-api
tools: alsactl,alsamixer,amixer
Server-1: PipeWire v: 0.3.75 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Wrong directions taken
I had no real idea where to start looking. If I recorded audio from my USB sound card I saw why the audio was chopped: after every N samples there would be a block of N zeros. I suspected everything and the kitchen sink… tried to verify my audio interface wasn’t dying; then I suspected a kernel update and found some posts on this forum (and on the internet) pointing to kernel regressions leading to audio problems. I noticed a USB spring cleanup commit in the kernel, and since I use an external USB audio interface, I then thought that might be a clue. But then I noticed the problem also happened on the onboard sound card. I also suspected a recent pipewire update (Actually, I still do… something must have changed somewhere? Or an interplay of multiple changes? Maybe some default configuration file contents changed? Not sure…). I read reports about changing default sampling rate, but that didn’t seem to make much difference.
Clues
Something I found by accident is that starting pavucontrol immediately resolved the chopped audio problem and stopping it immediately reintroduced it.
What kind of magic does pavucontrol posess?
Examination
pw-top when pavucontrol is running (audio ok)
pw-top when pavucontrol is not running (chopped audio)
Comparing the screenshots the QUANT column and wait value look radically different when pavucontrol is running. From the pipewire docs I learned that the QUANT value is set to a system default, unless an application explicitly selects a different one, in which case all programs inherit the lowest quantum in use. That sounded like a good candidate for explaining hidden magic.
As an experiment, I copied the file /usr/share/pipewire/pipewire-pulse.conf to ~/.config/pipewire/pipewire-pulse.conf, then edited the file and added a line in the context.properties section:
context.properties = {
default.clock.quantum = 256
}
Then I restarted the pipewire-pulse service using the command
systemctl --user restart pipewire-pulse
And audio sounds perfect again.
)). And that’s doable.
)