Microphone distorted sound on ALC892/1220 on AMD chipsets

Bug #1801540 reported by Luca Osvaldo Mastromatteo
44
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Linux
Confirmed
Medium
linux (Ubuntu)
Won't Fix
Undecided
Unassigned
pulseaudio (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Not sure if I'll report this upstream but there is definitely an issue with microphone recording on my desktop, this is not happening on my laptop which has a different codec.

Already tried all workarounds possible, no luck. Only with my desktop with this particular motherboard. No issues in Windows, the sound recorded in there is distorted and has some static and robotic tone on high-pitch.

alsa-info on the attachments

Tags: cosmic
Revision history for this message
In , icebalm (icebalm-linux-kernel-bugs) wrote :

Audio playback seems to be fine, however audio capture results in crackling.

- all values of position_fix have been tried and do not help
- power_save=0 does not help
- align_buffer_size does not help
- enable_msi does not help

Hardware is onboard ALC1220 codec sound chipset on the ASUS Crosshair VI Hero motherboard.

Revision history for this message
In , kernel (kernel-linux-kernel-bugs) wrote :

Created attachment 257067
alsa-info of offending hardware

Revision history for this message
In , kernel (kernel-linux-kernel-bugs) wrote :

To elaborate on this bug:

- I've found someone on reddit who went into more detail (including futile pulseaudio sorcery): https://www.reddit.com/r/linuxquestions/comments/68rirb/mic_cracklingstatic/
- He was kind enough to upload an audio sample: https://drive.google.com/open?id=0B1kXCJ6A8v29N3lBT0c4TGdRbFE

I have encountered the same problem. It is present from 4.11 to 4.12.0-rc5 (most recent rc as of this writing). I tried a few distros; all have the same problem.

Windows 10 records without distortion.

This device identifies as "Vendor Id: 0x10ec1168". See attached alsa-info file and ignore the ATI HDMI and Audioengine noise as best as possible.

38 comments hidden view all 349 comments
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :
affects: alsa-lib (Ubuntu) → alsa-driver (Ubuntu)
15 comments hidden view all 349 comments
Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

Created attachment 279301
alsa-info

I always got this issue only on Linux, every distro I tried including Manjaro Linux, Debian, ubuntu had this problem.

Basically the microphone input sounds always distorted and "robotic" even on high pitch. In all the programs I tried.

Workarounds as listed on the ArchWiki ---> https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Microphone_crackling_with_Realtek_ALC892 have not changed anything.

Interesting thing though is that on FreeBSD this does not happen.

alsa-info on the attachments

Kernel version: Linux luky-MS-7A37 4.18.0-10-generic #11-Ubuntu SMP

alsa-version
Driver version: k4.18.0-10-generic
Library version: 1.1.6
Utilities version: 1.1.6

Obviously this also happens on other kernels.

14 comments hidden view all 349 comments
Revision history for this message
Cristian Aravena Romero (caravena) wrote :

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1801540

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

I tried running it, I don't know honestly if that worked because when I clicked on that link a browser page just appeared showing nothing relevant

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Cristian Aravena Romero (caravena) wrote :

https://help.ubuntu.com/community/ReportingBugs
--
Cristian Aravena Romero (caravena)

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Uhm yes I know that, but apport-collect is just not working as I already said...

Revision history for this message
Hui Wang (hui.wang) wrote :

Does this issue happen on Front Mic, Rear Mic or LineIn?

set the input volume lower, is the recorded sound better?

tags: added: cosmic
affects: alsa-driver (Ubuntu) → pulseaudio (Ubuntu)
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

1) Happens with both Front mic and Rear mic.

2) No, it still sounds bad.

Something I found is that on FreeBSD is working fine.

Revision history for this message
Hui Wang (hui.wang) wrote :

Probably the FreeBSD is working as Windows, they use the software de-noise filter when users record sound.

Please test with "pactl load-module module-echo-cancel", then choose echo-cancelled record device from gnome-sound-setting->input tab. Now record sth, and play it. Is it better now?

If there is sth in the kernel driver to introduce the noise, the thing I can figure out so far is change the micbias reference voltag:
Right now the reference for two mics:
Rear Mic: Pin-ctls: 0x21: IN VREF_50
Front Mic: Pin-ctls: 0x24: IN VREF_80

You can try to set them with different value like "HIZ 50 GRD 80 100", maybe some value can improve the sound quality.

The patch_realtek.c has some sample code to set verf.

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

So yes even with the module-echo-cancel enabled is still happening, I'll try modifying the realtek patch on the kernel

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Tried all those values through HDAAnalyzer, but nothing relevant changed, the noise is still there.

A note: In Windows or FreeBSD i was not using any echo cancel software, the noise is just not present. There is still tjhe normal environmental one, but not the robotic one only present on Linux.

Here is a recording, amplified so you can easily hear the noise in question. If I don't amplify the input, the noise is still there, just the volume is low.

7 comments hidden view all 349 comments
Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

Created attachment 279675
Recording showing the noise

6 comments hidden view all 349 comments
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Any updates on this?

Revision history for this message
Hui Wang (hui.wang) wrote :

@Luca,

I have no idea what is the root cause of this problem and how to fix it.

Please file a bugzilla bug against the mainline linux kernel, let us ask for help from mainline kernel community where realtek engineer probably will be involved.

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Yes I already did that but I may not understand how to add the required maintainers into the mailing list

Here is it
https://bugzilla.kernel.org/show_bug.cgi?id=201613

5 comments hidden view all 349 comments
Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

I may confirm that recording without pulseaudio using ffmpeg -alsa produces the same disturbed sound

4 comments hidden view all 349 comments
Revision history for this message
Hui Wang (hui.wang) wrote :

you might have a try with adding <email address hidden> and <email address hidden> to the CC list.

And send an email to them with cc <email address hidden> would be better.

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Done, for sending an email to them using that CC you mean without the bugzilla site?

Should I just put the bugzilla link in that email?

Revision history for this message
Hui Wang (hui.wang) wrote :

put the bugzilla link in the email.

3 comments hidden view all 349 comments
Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

Motherboard model is an MSI B350M AM4 for Ryzen CPU's

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Launchpad Janitor (janitor) wrote : Re: Microphone distorted sound on ALC892

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in pulseaudio (Ubuntu):
status: New → Confirmed
Revision history for this message
Paul (p4ul1) wrote :

I have exactly the same problem, and I also have an MSI B350 am4 motherboard...

Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

There are other people having the same issue on the same motherboard model

Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

A partial workaround which doesn't completely fix the issue but improves things is the following:

Adding to /etc/pulse/default.pa, use_ucm=0 tsched=0 right after module-udev-detect

and /etc/pulse/daemon

resample-method = src-sinc-best-quality
default-sample-format = s16le
default-fragment-size-msec=80
default-sample-rate = 48000

Don't know which what specific parameter improved this, because when I test each one of those singularly doesn't totally fix the problem.

The best results I can obtain are with all those combined

Revision history for this message
In , lukycrociato (lukycrociato-linux-kernel-bugs) wrote :

Actually this workaround adds another problem, in games the sound is delayed...

Revision history for this message
Christopher Smith (canadauni) wrote : Re: Microphone distorted sound on ALC892

Following up that I'm experiencing the same issue on an MSI B450 AM4 motherboard with the same realtek chipset.

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Seems to be the same problem as https://bugzilla.kernel.org/show_bug.cgi?id=195303
With ALC1220 codecs

The last comment was

 "I might have found the source of this problem at least for me. A while ago I set my Pulseaudio sample rate to 44100 to reduce crackling in my virtual machine audio but the sound card on my board runs at 48000.

What I did:
arecord --list-devices
arecord -f dat -r 60000 -D hw:CARDIDHERE,DEVICEIDHERE -d 5 test.wav

arecord told me that it could not record of a rate of 60000 and instead got 48000. This means my card has a sample rate of 48000

So I ran:
arecord -f dat -r 48000 -D hw:1,0 -d 5 test.wav

And suddenly I had a clear recording! The only problem is I have changed my sampling rate and alternate sample rate in /etc/pulse/daemon.conf back to 48000 but it still seems to be defaulting to 44100 in all programs.

If I run:
arecord -f cd -d 10 test-mic.wav
I observe it defaulting to 44100 and playing it back sounds awful again. Same with any other recording software, they are all still using 44100 for some reason which is causing the crackling."

This also applies to me, is there a temporary workaround for that I can apply to ALSA or Pulseaudio?

Revision history for this message
fred (fredmeissner) wrote :

i've the same Problem on Ubuntu 18.10.
I'm running a Asus P9D-X (no Onboard Sound) with a Asus MIO 892 (Realtek)-Card which is detected as Intel-HDA:
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)

cat /proc/asound/cards :
0 [PCH ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xd3210000 irq 35

head -n 1 /proc/asound/card0/codec* :
Codec: Realtek ALC892

lsmod | grep "^snd" | cut -d " " -f 1 :
snd_seq_dummy
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
snd_hda_intel
snd_hda_codec
snd_hda_core
snd_hwdep
snd_oxygen
snd_oxygen_lib
snd_mpu401_uart
snd_pcm
snd_seq_midi
snd_seq_midi_event
snd_rawmidi
snd_seq
snd_seq_device
snd_timer
snd

Revision history for this message
fred (fredmeissner) wrote :

Got it fixed by in with my MIO-892:

/etc/pulse/daemon.conf:
default-sample-rate = 48000

/etc/modprobe.d/azalia-microphone.conf
#Valid values for position_fix are:
#0 = Auto
#1 = None
#2 = POSBUF
#3 = FIFO size
options snd-hda-intel position_fix=0

For Echo/Noise Cancellation:
/etc/pulse/default.pa
load-module module-echo-cancel use_master_format=1 aec_method=webrtc aec_args="analog_gain_control=0 digital_gain_control=1" source_name=echoCan$
set-default-source echoCancel_source
set-default-sink echoCancel_sink

Its mainly taken from the arch-wiki - but only 'this' combination worked for me.

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Tried that, it does not work for me

Daemon.conf has sample rate of 48000 even in my case, and setting that module parameter still did not fix anything

I'm stuck with an USB sound card again

AMD chipset, ALC892 realtek codec

1 comments hidden view all 349 comments
Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :

Just for curiosity, how did you test if it works or not?

I personally use this web program https://webcammictest.com/check-microphone.html

So I can hear myself, and for me it is still present with every workaround I try...

Revision history for this message
In , alex32.com (alex32.com-linux-kernel-bugs) wrote :

I have the same problem with MSI B450 Tomahawk Motherboard

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote : Re: Microphone distorted sound on ALC892

Some info regarding this, looks like a common problem with also other different codecs and the only thing in common is the AMD chipset.

The same codecs on Intel looks to play just fine

Revision history for this message
Luca Osvaldo Mastromatteo (lukycrociato) wrote :
summary: - Microphone distorted sound on ALC892
+ Microphone distorted sound on ALC892/1220 on AMD chipsets
Revision history for this message
Kostas Papadopoulos (kpu) wrote :

Bug 195303 (ALC1220 snd_hda_intel Sound capture is crackled / distorted) is the most detailed and active of several open bug reports about this.

Changed in linux:
importance: Medium → Unknown
status: Confirmed → Unknown
Revision history for this message
Kostas Papadopoulos (kpu) wrote :

Most reports mention ALC1220, but the same bug occurs in older AMD systems also.

E.g. it occurs on a 2014 system by Dell, AMD chipset, AMD G-T48E CPU, ALC269VB, with Linux 4.19.
Whereas the microphone of that system works OK with Windows 10.

**** List of PLAYBACK Hardware Devices ****
card 0: Generic [HD-Audio Generic], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: SB [HDA ATI SB], device 0: ALC269VB Analog [ALC269VB Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

**** List of CAPTURE Hardware Devices ****
card 1: SB [HDA ATI SB], device 0: ALC269VB Analog [ALC269VB Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Changed in linux:
importance: Unknown → Medium
status: Unknown → Confirmed
Changed in pulseaudio (Ubuntu):
status: Confirmed → Won't Fix
Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
272 comments hidden view all 349 comments
Revision history for this message
In , vinayshastry (vinayshastry-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #269)
> For all people who still see the problem: please test 5.3-rc6 or rc7 kernel
> and confirm that the problem persists.

Tried with 5.3-rc6

Problem: Distorted sound with steam voice chat with 1022:1457.

> 1. Change the return value of azx_get_delay_from_fifo() to 0, e.g.

Didn't help.

> 2. Change the return value of azx_get_delay_from_fifo() to 0 only for
> playback, e.g.

Didn't help.

> 3. Drop SNDRV_PCM_INFO_BATCH workaround in hda_controller.c

This fixed it!
Normal sound on steam voice chat (also ok on skype, discord web) - with front mic jack as well as usb webcam.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

OK, that's good to know.

And how is the application set up? Does it run over PulseAudio backend or accesses directly ALSA devices?

The BATCH workaround was needed for PulseAudio. Does any other application using PulseAudio (wrt capture) work on your device?

And it'd be strange if this setup change makes any difference on USB webcam behavior. If so, it must be a bug in PulseAudio.

Revision history for this message
In , vinayshastry (vinayshastry-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #271)
> And how is the application set up? Does it run over PulseAudio backend or
> accesses directly ALSA devices?

Everything on PulseAudio.
(Using a standard gnome desktop.)

> The BATCH workaround was needed for PulseAudio. Does any other application
> using PulseAudio (wrt capture) work on your device?

Well, I've also tried arecord, gnome-sound-recorder.
These and Skype work with and without the BATCH workaround.

Steam and Discord have severe issues with the workaround.

> And it'd be strange if this setup change makes any difference on USB webcam
> behavior. If so, it must be a bug in PulseAudio.

The patch seems to trigger the issue as long as the device is in use - even if just for playback.

With the workaround, if I use HDMI output and USB webcam, the sound is OK (i.e, this device not in use).
Sound card's line-out + any input source causes problem.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

Hmm, would it be only about playback? That is, restricting the workaround only to capture stream works better?

--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -617,7 +617,8 @@ static int azx_pcm_open(struct snd_pcm_substream *substream)
         * tsched=1 when a capture stream triggers. Until we figure out the
         * real cause, disable tsched mode by telling the PCM info flag.
         */
- if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND)
+ if ((chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) &&
+ substream->stream == SNDRV_PCM_STREAM_CAPTURE)
                runtime->hw.info |= SNDRV_PCM_INFO_BATCH;

        if (chip->align_buffer_size)

In anyway, we need to know this change makes sense at all. IOW, people need to check whether this causes yet another regression on the devices that have worked with BATCH workaround.

Revision history for this message
In , gort818 (gort818-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #269)
> For all people who still see the problem: please test 5.3-rc6 or rc7 kernel
> and confirm that the problem persists.

Tried with 5.3-rc6

Problem: Distorted sound with steam voice chat with 1022:1487.

# 3 Worked for steam voice chat but unfortunately not in game eg. Counter-Strike: Global Offensive

Discord is mic is now distorted unless I set tsched=0 but if I set that then Steam chat is distorted.

I will check the above patch shortly

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #273)
> Hmm, would it be only about playback? That is, restricting the workaround
> only to capture stream works better?
>
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -617,7 +617,8 @@ static int azx_pcm_open(struct snd_pcm_substream
> *substream)
> * tsched=1 when a capture stream triggers. Until we figure out the
> * real cause, disable tsched mode by telling the PCM info flag.
> */
> - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND)
> + if ((chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) &&
> + substream->stream == SNDRV_PCM_STREAM_CAPTURE)
> runtime->hw.info |= SNDRV_PCM_INFO_BATCH;
>
> if (chip->align_buffer_size)
>
>
> In anyway, we need to know this change makes sense at all. IOW, people need
> to check whether this causes yet another regression on the devices that have
> worked with BATCH workaround.

With the standard flags, Discord is perfect, Steam has stutters for the first minute and a bit of delay (500 ms).

With the batch flag only on the capture stream, Steam is perfect, Discord has delayed audio.

With the batch flag only on the playback stream, same thing with both of them (first case).

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

Following my previous post, disabling the batch flag on both streams (patch 3 from comment 269), Steam is perfect, Discord is lagged again while acquiring.

With the second patch from the comment 269, same identical problem without the patch (Discord perfect, Steam crackling for the first minute + audio slightly delayed). However when changing volume there was a little bit of distortion on the output audio (extremely small, but still audible, especially on high volumes), but it seems that using the workaround only on acquisition seems to have removed that small issue. If someone here had the same problem when changing volume, please try patch n.2 and report back.

It seems that we can't have both working together simultaneously on my end. The default workaround is still the best option on my system, for now.

Revision history for this message
In , albertogomezmarin (albertogomezmarin-linux-kernel-bugs) wrote :

in the final release of Linux 5.3 are going to be these patches?
I ask because I am buying an amd laptop right now with ryzen 5 3550 H and want to know how was going this problem !
In an acer swift with AMD ryzen I had the problem

Revision history for this message
In , jg.staffel (jg.staffel-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #271)

(In reply to Takashi Iwai from comment #249)
> (In reply to al from comment #248)
> > Thanks that did it works great now!
>
> OK, I'll add the entry for 1022:1487 in the upstream, too.

The patch was backported to the 4.19.67 kernel.

With this and latest Gentoo stable kernel 4.19.72 and net-im/telegram-desktop-bin-1.8.8 my companion hear myself while audio call. No echo cancellation.

ASRock Fatal1ty B450 Gaming K4
ALC892, [1022:1457] subsys [1849:9893]

Revision history for this message
In , kode54 (kode54-linux-kernel-bugs) wrote :

This patch, as applied to the latest 5.3 kernel, is not working on my SO's desktop machine, running Arch Linux, still glitching in Discord voice chat.

Gigabyte Aorus B450 Pro Wi-Fi
ALC1220, [1022:15e3] subsys [1458:a0c3]

alsainfo, if useful:

http://alsa-project.org/db/?f=105ba36f537312d1119e5f9ea5810a86ac4db68d

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

Yours has a different controller chip, so the patch doesn't have any effect as is.

Try a freshly submitted / merged patch on top of the previous fixes:
  https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d2c63b7dfd06788a466d5ec8a850491f084c5fc2

Revision history for this message
In , albertogomezmarin (albertogomezmarin-linux-kernel-bugs) wrote :

(In reply to Takashi Iwai from comment #280)
> Yours has a different controller chip, so the patch doesn't have any effect
> as is.
>
> Try a freshly submitted / merged patch on top of the previous fixes:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/
> ?id=d2c63b7dfd06788a466d5ec8a850491f084c5fc2

Will this patch be in the future stable Linux releases ? I mean if Linux 5.3.1 will have this patch by default.
It is curiosity because I don't know how Linux versions works

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

(In reply to Marco from comment #276)
> Following my previous post, disabling the batch flag on both streams (patch
> 3 from comment 269), Steam is perfect, Discord is lagged again while
> acquiring.
>
> With the second patch from the comment 269, same identical problem without
> the patch (Discord perfect, Steam crackling for the first minute + audio
> slightly delayed). However when changing volume there was a little bit of
> distortion on the output audio (extremely small, but still audible,
> especially on high volumes), but it seems that using the workaround only on
> acquisition seems to have removed that small issue. If someone here had the
> same problem when changing volume, please try patch n.2 and report back.
>
> It seems that we can't have both working together simultaneously on my end.
> The default workaround is still the best option on my system, for now.

The second patch cited in my previous post is necessary now (under 5.3.5, not sure about the previous kernel versions); besides the small crackles when changing volumes, the acquisition from the microphone under load (compilation, for example) sometimes becomes extremely low quality (like if the sample rate is changing randomly and often the audio is clipping). Applying the patch only on the capture stream completely fix the issue, no crackles when changing volume and no issue when acquiring audio with Discord under load.

Steam still shows random audio stutters while acquiring for a minute and a bit of delay, so that is still unchanged, unfortunately.

Revision history for this message
In , bkrippner (bkrippner-linux-kernel-bugs) wrote :

Confirming this for ALC887-VD Analog [ALC887-VD Analog]

Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller [1022:780d] (rev 01)

Crackling seems to only go away when mix is set to lower than 10% in pulseaudio. If the device oversaturates it seems to try to lower the volume and starts to crackle for a while making it unusable to record or talk for a long time. This has been around for a long time now.

It seems there is already a patch but im kinda worried by the version number. 5.3.x seems pretty far away from stable releases(5.0.0-27-generic)?

Revision history for this message
In , khaledaldajani98 (khaledaldajani98-linux-kernel-bugs) wrote :

Why the issue is back?
i remember in Linux kernel 5.3 RC7 it was fixed but now it's back my audio codec is ALC887-VD

Revision history for this message
In , adam.reichold (adam.reichold-linux-kernel-bugs) wrote :

The problem still seems to affect Raven Ridge ([1022:15e3] in a HP ProBook 455R G6) using kernel version 5.6.4.

Disabling the SNDRV_PCM_INFO_BATCH workaround subjectively improves capture quality using `parecord` but it is not really usable either way.

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

Updates on this long endeavor as of today: I choose to give another try for switching from PulseAudio to the PipeWire sound server.

The problems are completely gone. No audio clicking anywhere on the system.
I have tried one month ago, but on reboot I was not having any audio coming out from the system. Now everything worked on install right from the get go. Tried also the mic under Steam, which always had audio clicking issue while acquiring and audio stalling (don't remember under what condition); acquisition is now perfect. Tried to dual test recording from Steam Voice and Discord while playing audio, no delay, no crackling, no issue. All streams are working simultaneously. I still have not long tested this, by the way, but on a first impression, yes, it fixed a lot of issues for me.

The only minor configuration issue was to switch the microphone detection method in the PipeWire configuration file, otherwise no microphone were detected. After that, everything work as it should, for now.

The issue on my end was definitely PulseAudio. If you still have problems, try PipeWire if you can or if fits your needs. This definitely solved my problems, maybe it will help yours too.

Marco.

Revision history for this message
In , korrode (korrode-linux-kernel-bugs) wrote :

FYI, the 'solution' for this issue that is now in the kernel breaks capturing screen+currrently playing audio with ffmpeg, for me at least, on AMD Raven hardware.

I tried many things but could not achieve good audio capture that is synchronised, not when capturing from Pulse anyway.

I'm guessing it's being in BATCH mode, and Pulse not operating with tsched, that is the problem, not the rest of the patchwork.

Nonetheless I just wanted things to work as before without any doubt, so I now have my kernel patched with the following (restoring 1022:15e3 to use the parameter sets it used to before all this) and everything is working fine now:

diff -Naur a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
--- a/sound/pci/hda/hda_intel.c 2021-02-10 19:29:23.000000000 +1100
+++ b/sound/pci/hda/hda_intel.c 2021-02-14 02:42:38.714796278 +1100
@@ -2601,7 +2601,8 @@
     AZX_DCAPS_PM_RUNTIME },
  /* AMD Raven */
  { PCI_DEVICE(0x1022, 0x15e3),
- .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_AMD_SB },
+ .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB |
+ AZX_DCAPS_PM_RUNTIME },
  /* ATI HDMI */
  { PCI_DEVICE(0x1002, 0x0002),
    .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS },

--
While I greatly appreciate the work on the microphone input crackling issue (which I have experienced and been annoyed by myself over the years), i'm concerned that the current solution should've been further tested and developed before being mainlined.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

That's a good discovery. This change makes sense, as the different of PRESET_ATI_SB from PRESET_AMD_SB is about the position reporting. ATI_SB uses the legacy LPIB register read while AMD_SB uses the position buffer table.
This could be verified by changing position_fix module option: 1 is LPIB and 2 is position buffer.

If we can confirm that this change generally improves the behavior, I can merge the fix quickly to the upstream. Can anyone else check it?

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

... and looking back at the development history again, this seems too early to be delighted. Actually the change to PRESET_AMD_SB was done as a fix for the certain devices in the commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2
    ALSA: hda - Apply AMD controller workaround for Raven platform

So moving it back would break something else, too. Hmm.

That said, the behavior might depend on the PCM parameters, or the chip revision, BIOS, or whatever subtle things...

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

Again a correction: the current default setup for Raven corresponds to position_fix=6 option. It's not a simple LPIB read but contains some awkward correction that takes the FIFO size into account.

Revision history for this message
In , korrode (korrode-linux-kernel-bugs) wrote :

@Takashi Iwai

> So moving it back would break something else, too. Hmm.

Indeed, it will break whatever solutions to the original issue of microphone input crackling your changes may have fixed for this sound device.

My use case - capturing from the global output monitor - has never had a crackling issue, but is completely broken by the changes.

It's a difficult situation.

Revision history for this message
In , korrode (korrode-linux-kernel-bugs) wrote :

I should clarify: My broken use case is capturing from the global output monitor while also capturing the screen, and having the audio be synchronised like at capture time.

In some of my early tests the audio was not only un-synchronised, but had other issues too (jolting, etc.), so it's possible even just capturing from the audio monitor alone has issues, but i haven't confirmed that.

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

(In reply to Rob McCathie from comment #292)
> I should clarify: My broken use case is capturing from the global output
> monitor while also capturing the screen, and having the audio be
> synchronised like at capture time.
>
> In some of my early tests the audio was not only un-synchronised, but had
> other issues too (jolting, etc.), so it's possible even just capturing from
> the audio monitor alone has issues, but i haven't confirmed that.

I have tested this (if i have done it correctly, taken from https://trac.ffmpeg.org/wiki/Capture/Desktop for pulse acquisition, using PipeWire), and besides a small audio missing at the start of the recording of about one second and at the end of it (but that was maybe caused to the ctrl-c to ffmpeg, I'm not sure about that), it looks pretty much synchronized to me, using a microphone next to my mouse and selecting text on the screen I can't really see any delay on it (on the current implemented workaround, Kernel 5.11)

Mind you, I'm on a 0x1487 and not on a 0x15e3 host side controller (not an "AMD Raven"), so maybe the behavior of the two controllers are different from each other (or PipeWire is not causing the issue here).

Marco.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

1487 is with the same setup as Raven (15e3), and the same workaround is applied.

Please note that the workaround isn't actually delaying the sound transfer. Instead, it reports the PCM delay value up to 32bytes for FIFO size for the applications. If the application (the sound backend) doesn't take the delay attribute into account, it's of course unaffected. I don't know whether PipeWire behaves properly for the delay evaluation, though.

Revision history for this message
In , korrode (korrode-linux-kernel-bugs) wrote :

Indeed.

My issue relates to usage with Pulse.

PipeWire looks like an interesting up-and-coming project, but right now Pulse is what is rolled out in the vast majority of distros and, for now, tales of outcomes with PipeWire aren't so useful.

Revision history for this message
In , korrode (korrode-linux-kernel-bugs) wrote :

Just thought i'd update on my situation, i've now tested that it is only the Pulse changing to batch mode that causes my issue. So i'm no longer running the patch i posted earlier, rather now i do this:

diff -Naur a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
--- a/sound/pci/hda/hda_controller.c 2021-02-10 19:29:23.000000000 +1100
+++ b/sound/pci/hda/hda_controller.c 2021-02-14 00:38:36.602466066 +1100
@@ -609,13 +609,6 @@
          20,
          178000000);

- /* by some reason, the playback stream stalls on PulseAudio with
- * tsched=1 when a capture stream triggers. Until we figure out the
- * real cause, disable tsched mode by telling the PCM info flag.
- */
- if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND)
- runtime->hw.info |= SNDRV_PCM_INFO_BATCH;
-
  if (chip->align_buffer_size)
   /* constrain buffer sizes to be multiple of 128
      bytes. This is more efficient in terms of memory

------------------

It's my opinion that the above reversion should be done in mainline. A bugfix that fixes a problem over here but creates a new one over there isn't a bugfix at all.

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

(In reply to Rob McCathie from comment #296)
> Just thought i'd update on my situation, i've now tested that it is only the
> Pulse changing to batch mode that causes my issue. So i'm no longer running
> the patch i posted earlier, rather now i do this:
>
>
>
> diff -Naur a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c
> --- a/sound/pci/hda/hda_controller.c 2021-02-10 19:29:23.000000000 +1100
> +++ b/sound/pci/hda/hda_controller.c 2021-02-14 00:38:36.602466066 +1100
> @@ -609,13 +609,6 @@
> 20,
> 178000000);
>
> - /* by some reason, the playback stream stalls on PulseAudio with
> - * tsched=1 when a capture stream triggers. Until we figure out the
> - * real cause, disable tsched mode by telling the PCM info flag.
> - */
> - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND)
> - runtime->hw.info |= SNDRV_PCM_INFO_BATCH;
> -
> if (chip->align_buffer_size)
> /* constrain buffer sizes to be multiple of 128
> bytes. This is more efficient in terms of memory
>
>
>
> ------------------
>
> It's my opinion that the above reversion should be done in mainline. A
> bugfix that fixes a problem over here but creates a new one over there isn't
> a bugfix at all.

FWIW, on my system this improves the recording start, removing completely audio clicks at the start of recording (no audio stalls in reproduction, even with multiple streams on acquisition while playing audio), so for my use case it's fine, but someone with PulseAudio should test this and see if it causes regressions.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

Yes, that's merely an ugly workaround, and I'd happily get rid of it once after confirming it's working fine without that!

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

OK, I'm going to submit this partial revert.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

Created attachment 295735
The partial revert patch

Revision history for this message
In , adrien.dessemond (adrien.dessemond-linux-kernel-bugs) wrote :

I hit this issue as well on my Gentoo box (see https://bugs.gentoo.org/779157).

After applying the patch mentioned in comment #296, the audio is back to normal with PulseAudio, no more distortions, the audio is clean. No perceived audio lags. Everything is in working order again.

Tested only with 5.10.24 and 5.10.26 here, will test with a 5.11.x kernel later.

Revision history for this message
In , adrien.dessemond (adrien.dessemond-linux-kernel-bugs) wrote :

Any update on this? Perhaps I have a misunderstanding, however the issue is still here unless I do a patch -R with what is in comment #296. Even with the latest 5.11.13...

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

Update after the latest firmware update for the platform, called AMD AGESA V2 PI 1.2.0.3 Patch A, released yesterday for my platform, finally. This includes the USB patch for the drop in the USB communication under load for too much recovery errors hitting the Pci-Ex subsystem on the chipset, apparently, that was only present when using Pci-Ex 4 (B5xx and X5xx, not on b4xx, in theory).

However, the USB issues was still present even on older platform, apparently. Just not as grave as the 500 series.

The audio clicking is completely gone and the machine is finally much more responsive; I've yet have to test the system under high loads, but even on the desktop the audio clicking was audible sometimes, when event from application fires; after the firmware update, this is completely disappeared. The audio now is perfect, at least in output. I'll update here as soon as I can test the recording now.

I didn't think it would change much. But, for me at least, it did.

Revision history for this message
In , rodomar705 (rodomar705-linux-kernel-bugs) wrote :

After some gaming and streaming, I can confirm that I haven't heard anymore pops or clicks, and a lot of performance issues completely disappeared after applying this firmware, like microstutters in the system under load and such. Kinda makes sense, since PciEx is basically the main bus where everything is connected on a modern PC; I guess better late than never.

I'll keep monitored the situation, but I think that at least for me after this firmware update the issue has been finally fixed.

Revision history for this message
In , haro41 (haro41-linux-kernel-bugs) wrote :

(In reply to Frédéric Pierret from comment #5)
> Hi,
>
> I also had the same problem with my ASROCK X370 Gaming K4 (ALC1220):
>
> 1st case: Booting FIRST Linux: Sound with noise/crackling.
> 2nd case: Booting FIRST Windows and SECOND Linux: Sound is perfect.
>
> I suceed in solving the problem by comparing the Coeff values in both cases
> and assign the values of the second case in a script at boot time. How to:
>
> - Install alsa-tools.
> - In both cases, you have to: echo 1 >
> /sys/module/snd_hda_codec/parameters/dump_coefs
> - Then, in the first case, alsa-info --no-upload --output infos_bad
> - Then, in the second case, alsa-info --no-upload --output infos_good
> - Finally, you compare the coef values: diff infos_bad infos_good | grep
> Coeff
>
> For changing the value of each different Coeff, you need to proceed as
> follow: for example, changing Coeff 0x67 to value 0x3000
>
> hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67
> hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000
>
> You have to do this in the growing order of Coeff. Remark that hwC0D0 refers
> to your sound card. In case of HDMI output like me, my sound card if hwC1D0.
>
> Here is a quick script:
>
> ------------------------------------------------------------------------
> #!/bin/bash
>
> coeffs=($(echo 0x{16,43,44,5d,5e,63,67}))
> values=($(echo 0x{8020,3405,fa10,0606,0000,e430,3000}))
>
> for i in `seq 0 $(( ${#coeffs[@]} - 1 ))`
> do
> hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX ${coeffs[$i]} && hda-verb
> /dev/snd/hwC1D0 0x20 SET_PROC_COEF ${values[$i]}
> done
> ------------------------------------------------------------------------
>
> Just change the coeffs to change in the array 'coeffs' and the new values in
> array 'values' and exec this script. A remark, while I do not shutdown the
> power supply, my audio chipset keeps the values. This is why you need to do
> the FIRST case (first...) and then the second. Then, you could test if it
> works only when you shutdown the power supply of your mobo and then booting
> into Linux directly.
>
> I'm preparing a patch for the kernel but for those who have the problem,
> could you post your coeff/values which need to be change please.
>
> Hope this helps.

Hi Frederic,
thank you for sharing your approach and script.
It helped me to solve a problem with my ALC3234 (Dell Optiplex 3040 Micro). The analog output format was limited to 44.1kHz/48kHz after direct linux boot. With a previous Windows boot, additional 96kHz/192kHz are available.

I will attach the adapted script, that works for me. May be it helps someone.

Revision history for this message
In , haro41 (haro41-linux-kernel-bugs) wrote :

Created attachment 304321
script to adapt alc3234 codec coefs

Revision history for this message
In , pshou (pshou-linux-kernel-bugs) wrote :

Created attachment 304349
patch_realtek_alc1220_record.diff

Hi all:

Basically, ASUS CROSSHAIR VI HERO only provides Windows version, not Linux version.

You can try it, after entering the LINUX OS (ALC1220, 0x10ec1022, subsytem ID: 10438735)
"sudo su root" type root password
"hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x15"
"hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x06e0"
"hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x6f"
"hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0xc03b"
Try recording, will it still break?

If possible, please install the PATCH file in the LINUX Kernel source and try it out.

Best regards
pshou

-----Original Message-----
From: <email address hidden> <email address hidden>
Sent: Thursday, May 25, 2023 8:13 PM
To: Pshou <email address hidden>
Subject: [Bug 195303] AMD HD-audio controller: Sound capture is crackled / distorted

External mail.

https://bugzilla.kernel.org/show_bug.cgi?id=195303

--- Comment #306 from <email address hidden> ---
Created attachment 304321
  --> https://bugzilla.kernel.org/attachment.cgi?id=304321&action=edit
script to adapt alc3234 codec coefs

--
You may reply to this email to add a comment.

You are receiving this mail because:
You are on the CC list for the bug.
------Please consider the environment before printing this e-mail.

Revision history for this message
In , tiwai (tiwai-linux-kernel-bugs) wrote :

For ASUS-specific codec issues, could you open another bug instead of hanging this old issue? The AMD controller problem was basically fixed, and the Realtek codec quirk is a different story.

Revision history for this message
In , haro41 (haro41-linux-kernel-bugs) wrote :
Displaying first 40 and last 40 comments. View all 349 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.