Strange Audio Issues After Updating

Help
1

On NixOS unstable with flakes and home-manager, and I use hyprland for my DE. I also use Wireplumber for audio.

I recently updated my nixpkgs and I’m having very strange audio issues. The vast majority of programs’ audio are crackling, stuttering, and even bitcrushing. This ranges sporadically from once every few seconds, to constantly.

But interestingly, audio from videos specifically do not have this issue. For example, watching a Youtube video, there is zero issue with the sound. Also, watching a video within VLC has no audio issues, but playing an audio file does. Videos are the only thing I have found so far that do not have audio issues currently.

I didn’t make any changes to my audio configuration before updating, and this was not a problem before then. I have tried with multiple audio sources, and they all have the same problem. Also, I switched to KDE Plasma to see if that would solve the issue, but it was still present in that environment.

2

I’m having a very similar issue after updating to 24.11, except that it’s all audio, including youtube in chrome and videos in vlc.

I booted back into 24.05 and verified the issue doesn’t happen.

While troubleshooting, I determined that the issue seems to go away if I disconnect my docking station (a Dell WD19TB). I reconnected it and verified the issue returns. I then simply moved the video window from my external monitor to the built in monitor and the stuttering went away! I move it back to the external monitor and it returns.

3

Post your config for more info.
Also, did you consult nixpkgs/nixos/doc/manual/release-notes/rl-2411.section.md at 3eeff54780a1a8c73c82ca51987962b62bd4219e · K900/nixpkgs · GitHub already ?

4

If you can, please do a first-parent bisect between the 24.05 branch-off and the current 24.11 to figure out when roughly when this regression was introduced.

https://wiki.nixos.org/wiki/Bisecting

5

I experience the similar behavior.

After updating nixpkgs to 24.11 I noticed that all audio is stuttering/cracking (sometimes it’s every few seconds, sometimes more like every minute, haven’t noticed any pattern). The issue is present for both headphones directly connected via jack port on motherboard and speakers connected through an USB audio card.

The issue is not present when I boot to 24.05.

My configuration is available on GitHub:

  • main branch: configuration used before upgrading from 24.05 to 24.11
  • feat/upgrade-24.11 branch: configuration with nixpkgs upgraded to 24.11 (and some minor tweaks not related with audio)

I was testing it for my PC machine. I haven’t applied the config for my laptop yet, I can try to check if the issue is present there as well.

@Atemu Could you please provide more info how to do the bisecting thing? Should I keep replacing the nixpkgs channel with a specific commit hash (until I find a specific one that breaks the audio)?

6

The linked wiki article explains it.

To test each commit, you’d nixos-rebuild test -I nixpkgs=/path/to/your/nixpkgs/checkout/.

7

Unfortunately, I didn’t have too much time a month ago to play with bisecting, as I was getting issues with catppuccin flake, so I gave up, and stuck with 24.05 for a while.

Finally, I decided to go with 24.11 again, I updated flake.lock, switched to the new config, rebooted, and… there was no audio issue.

And… after few days it went back again. I found that these errors were appearing in journalctl --follow output at the same time when I was hearing the audio crackling:

pipewire[2674]: pw.node: (alsa_output.usb-GeneralPlus_USB_Audio_Device-00.iec958-stereo-46) graph xrun not-triggered (0 suppressed)
pipewire[2674]: pw.node: (alsa_output.usb-GeneralPlus_USB_Audio_Device-00.iec958-stereo-46) xrun state:0x7fde55d9e008 pending:1/2 s:582961763255 a:582961786198 f:582961798311 waiting:22943 process:12113 status:triggered
pipewire[2674]: pw.node: (PulseAudio Volume Control-108) xrun state:0x7fde55d14008 pending:0/1 s:582967093084 a:582961771501 f:582961780818 waiting:18446744073704230033 process:9317 status:triggered
pipewire[2674]: pw.node: (alsa_input.usb-046d_HD_Pro_Webcam_C920-02.analog-stereo-45) graph xrun not-triggered (0 suppressed)
pipewire[2674]: pw.node: (alsa_input.usb-046d_HD_Pro_Webcam_C920-02.analog-stereo-45) xrun state:0x7fde5612c008 pending:1/2 s:582961966829 a:582961985655 f:582961986566 waiting:18826 process:911 status:triggered
pipewire[2674]: pw.node: (PulseAudio Volume Control-107) xrun state:0x7fde55d15008 pending:0/1 s:582967293953 a:582961975676 f:582961981447 waiting:18446744073704233339 process:5771 status:triggered
pipewire[2674]: pw.node: (alsa_input.pci-0000_0a_00.6.analog-stereo-71) graph xrun not-triggered (0 suppressed)
pipewire[2674]: pw.node: (alsa_input.pci-0000_0a_00.6.analog-stereo-71) xrun state:0x7fde55d99008 pending:1/2 s:582962635760 a:582962655147 f:582962656089 waiting:19387 process:942 status:triggered

I decided to debug it with Claude, and it said that PipeWire is failing to process audio data in time (buffer under-runs or over-runs). It could be related to the multiple devices connected (and it makes sense, as the crackling stared to appear again after connecting a web cam + reboot).

Claude suggested to update the quantum parameters:

"default.clock.rate" = 48000;
"default.clock.quantum" = 1024;
"default.clock.min-quantum" = 1024;
"default.clock.max-quantum" = 8192;

Before updating the PipeWire’s parameters in my NixOS configuration, I decided to change them temporarily with these commands:

pw-metadata -n settings 0 clock.force-rate 48000
pw-metadata -n settings 0 clock.force-quantum 2048

I went with 2048 as I was still hearing rare crackling with 1024 (everything seems to be good with 2048).

I haven’t update my NixOS config yet, but I assume this is going to fix my issue permanently:

  services.pipewire = {
    enable = true;
    extraConfig.pipewire = {
      "context.properties" = {
        "default.clock.rate" = 48000;
        "default.clock.quantum" = 2048;
        "default.clock.min-quantum" = 2048;
        "default.clock.max-quantum" = 8192;
      };
    };
  };

From what I read, increasing quantum (which is a audio data chunk processed by computer) can impact audio latency, but I haven’t noticed anything though