Microphone distorted sound on ALC892/1220 on AMD chipsets

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.

Created attachment 257067
alsa-info of offending hardware

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.

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.

Created attachment 279675
Recording showing the noise

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

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

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

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

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

I have the same problem with MSI B450 Tomahawk Motherboard

(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.

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.

(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.

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.

(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

(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).

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.

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

(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]

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

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

(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

(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.

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)?

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

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.

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.

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.

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?

... 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...

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.

@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.

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.

(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.

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.

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.

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.

(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.

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

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

Created attachment 295735
The partial revert patch

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.

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...

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.

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.

(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.

Created attachment 304321
script to adapt alc3234 codec coefs

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.

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.

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