Audio crackling in performance mode

Hello,

I am on the latest Manjaro GNOME. When in performance mode, all audio starts crackling. When set to balanced mode audio works alright. Happens both with pipewire and pulseaudio.

It happens on all Kernels after 5.4., but not on 5.4.

How can I fix it? Thank you.

System Details Report


Hardware Information:

  • Hardware Model: Lenovo Lenovo IdeaPad S145-15IWL
  • Memory: 16.0 GiB
  • Processor: Intel® Core™ i7-8565U × 8
  • Graphics: Intel® UHD Graphics 620 (WHL GT2)
  • Disk Capacity: 496.1 GB

Software Information:

  • Firmware Version: ASCN40WW
  • OS Name: Manjaro Linux
  • OS Build: rolling
  • OS Type: 64-bit
  • GNOME Version: Not Available
  • Windowing System: Wayland
  • Kernel Version: Linux 5.4.259-1-MANJARO

If noise is audible using pipewire and pulseaudio, I suggest disable power-saving for ALSA audio device temporarily

sudo tee /sys/module/snd_hda_intel/parameters/power_save <<< 0

and also try this in addition to previous change

sudo tee /sys/module/snd_hda_intel/parameters/power_save_controller <<< N

Changes are not persistent and can be reverted by reboot

Thanks for the message!

Unfortunately, these commands did not work. Any other ideas?

I suggest turn off PipeWire

systemctl --user stop pipewire-pulse.socket pipewire-pulse.service

and test audio playback direct to ALSA device: ALC236 Analog
( CARD=HDA Intel PCH DEV=0 or CARD=0 DEV=0 or hw:PCH,0 )
HW probe of Lenovo IdeaPad S145-15IWL 8... #1e700d65ea: aplay

If there is no crackling, issue is within PipeWire

If crackling is still audible in ALSA it is not a PipeWire issue

Thank you. I tried this with “speaker-test -c 2” but the test is done with pink noise, which means I can’t tell if there is any crackling.

speaker-test has additional options for test sounds:

speaker-test(1) — Arch manual pages

[-t | –test pink|sine|wav
-t pink means use pink noise (default).
-t sine means to use sine wave
-t wav means to play WAV files

Default .wav files are located in /usr/share/sounds/alsa

speaker-test -dhw:0,0 -c2 -l3 -twav

Hello, and sorry for the delay. I just got time to try this.

I turned off PipeWire and tried with the command you gave. There is audible crackling in the test.
So, this means it’s an ALSA issue? How do I go about solving it?

Thank you.

It is unlikely to be just an ALSA issue or crackling would be audible for all power states

I suggest you get full ALSA diagnostic for both power states

sudo alsa-info.sh --stdout >> alsa-performance.txt

and

sudo alsa-info.sh --stdout >> alsa-balanced.txt

and install meld (or similar) to compare the data in both text files
different timestamps are not relevant and can be disregarded

If you find any relevant differences in ALSA configuration, upload both text files to an online pastebin and post links to uploaded data here

Thank you.

Here is the alsa-balanced.txt
https://pastebin.com/bvqPSgjr

And here is the alsa-performance.txt
https://pastebin.com/yN3q3bvn

There were several differences between the files in Meld, but I could not understand anything since I am not an expert. Maybe you can help figure things out.

alsa-performance.txt is showing 2 alsa-info responses

  • !!Script ran on: Fri Dec 8 10:27:46 UTC 2023
  • !!Script ran on: Fri Dec 8 10:28:56 UTC 2023

8328 lines compared to 4276 lines for alsa-balanced.txt

alsa-balanced.txt is using kernel 6.1.64, but alsa-performance.txt kernel 6.6.3

Different modules shown in !!All Loaded Modules but they do not relate to audio devices in use


All 3 data sets show multiple modprobe options

!!Modprobe options (Sound related)
!!--------------------------------

snd_hda_intel: model=auto
snd_hda_intel: power_save=0
snd_hda_intel: power_save_controller=N
snd_hda_intel: power_save=0
snd_hda_intel: power_save=0 power_save_controller=N
snd_hda_intel: power_save=0

I suggest remove all of these options from /etc/modprobe.d/ folder
(or remove options in /etc/default/grub configuration and sudo update-grub)
then reboot system and check audio

If crackling is still audible, remove ALSA loopback device

modprobe -r snd-aloop 

If crackling is still audible, reboot system and run sudo alsa-info.sh --stdout > alsa-performance.txt for kernel v6.6

I followed the steps but unfortunately the crackling did not stop.

Here is the paste:

https://pastebin.com/BXU5K6MR

Most of the ALSA data looks ok, but audio capture levels are set to maximum:

Simple mixer control 'Capture',0
  Capabilities: cvolume cswitch
  Capture channels: Front Left - Front Right
  Limits: Capture 0 - 63
  Front Left: Capture 63 [100%] [30.00dB] [on]
  Front Right: Capture 63 [100%] [30.00dB] [on]

Simple mixer control 'Internal Mic Boost',0
  Capabilities: volume
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 0 - 3
  Front Left: 3 [100%] [30.00dB]
  Front Right: 3 [100%] [30.00dB]

Total of 60.0dB boost would make audio capture extremely noisy and distorted. The audio codec does not have microphone monitoring, but the excessive noise in audio capture could be inducing noise in the playback channels

I suggest set both levels to 0 and turn off audio capture:

amixer -c PCH 'Internal Mic Boost' 0; amixer -c PCH 'Capture' 0 nocap

The crackling sounds like it might be the audio buffering. I used to use DAWs a while back making music and if you set the sample buffer really short for low latency when using high sample rates the output caught up to the buffer it would crackle. This is tiny pauses in the audio that make popping sounds as it loads in the next bit of audio. So the settings you have might be making the audio buffer too short for the audio you are playing. Don’t know if you can control the audio buffer in Manjaro though. Definitely not your speakers.

With this command I get:

[lee@leenux ~]$ amixer -c PCH 'Internal Mic Boost' 0; amixer -c PCH 'Capture' 0 nocap

amixer: Unknown command 'Internal Mic Boost'...
amixer: Unknown command 'Capture'...

I tried configuring it through alsamixer c 0 but it did not help. I don’t know if it the same thing though.

I just tried booting a Fedora live USB, and the exact same audio bug appears there, too. Interesting.

Would this also happen in a live USB without me messing at all with the audio settings?