3

I have installed Ubuntu 24.04 on a new Lenovo IdeaPad 5 Pro 14 AMD 8845HS (Chinese version, called Xiao Xin Pro there). Everything works "out of the box", but there is a problem with the sound, presumably only in the Zoom 6.0.2 application. During a call, the sound "crackles" from time to time, both from the speakers and if you connect headphones.

What I tried:

  • I installed it both as an official deb package and as a flatpak - the problem is the same.
  • Checked - there is no problem in games, other programs, or Google Meet.
  • It works the same in the Wayland session and in the XOrg session.
  • It's as if the problem is that pipewire is being used. I tried to remove pipewire, at the same time I removed ubuntu-desktop somehow completely, and returned pipewire.

Where to look? What to do? Thank you

Dmitry Torshin
  • 141

1 Answers1

10

SO FINALLY I FOUND THE ROOT PROBLEM AND A SOLUTION!

I had the problem on Ideapad 5 Pro AMD 2024, Ubuntu 24.04 LTS and I spent around a week and this is the solution.

The problem in Ubuntu 24.04 caused some applications to produce crackling and popping sounds, as if there was interference. This occurred with both speakers and headphones.

Since Ubuntu 24.04 uses Pipewire by default, I had to investigate there. The issue turned out to be that "old" applications (such as Steam games through Proton or even the brand-new Zoom) use PulseAudio instead of Pipewire. This generates so-called xruns: "dropouts" in the audio subsystem of Pipewire. You can easily see them by running the pw-top command in the terminal and checking if the number in the ERR column is increasing and for which application.

The situation is complicated by the fact that in 24.04, you cannot roll back to PulseAudio: ubuntu-desktop is now permanently dependent on Pipewire and can only be removed along with it. Therefore, Pipewire must be kept and configured.

I found a very cool guide on setting this up, but it turned out to be overkill for our case (the guide is here). According to the guide, if the ERRs are growing only for the driver, then the problem lies there. If the ERRs are growing for both the application and the driver, then it's an application issue, which can be fixed by increasing the latency for that application (and only for it). To do this, run the application with PULSE_LATENCY_MSEC=126 COMMAND. You need to experiment with the number; the higher it is, the more the latency increases, which reduces audio processing problems but may affect sound quality. Through experimentation, I found that at 200, most problems disappeared, and at 300, all issues were resolved (this was when music was playing in the browser, a high-end 3D game was running through Proton, and a video conference was ongoing in Zoom).

To solidify the results, I adjusted two parameters in the Pipewire Pulse configuration file. Here's the step-by-step process:

  1. Copy the folder /usr/share/pipewire to /etc/pipewire (so the settings apply to all users and applications).
  2. Edit the file pipewire-pulse.conf in /etc/pipewire: 2.1. Find the pulse.min.quantum parameter and set it to 2048. Setting it to 1024 still caused failures under 100% load, but 2048 worked under any load. 2.2. Uncomment the next parameter: pulse.idle.timeout = 0.
  3. Restart Pipewire to ensure everything works: systemctl --user restart wireplumber pipewire pipewire-pulse. If everything is okay, we've succeeded!
Dherik
  • 383
Dmitry Torshin
  • 141