Bug 195303 - AMD HD-audio controller: Sound capture is crackled / distorted
Summary: AMD HD-audio controller: Sound capture is crackled / distorted
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-04-09 18:55 UTC by icebalm
Modified: 2023-06-05 10:51 UTC (History)
69 users (show)

See Also:
Kernel Version: 4.11.0-rc5
Subsystem:
Regression: No
Bisected commit-id:


Attachments
alsa-info of offending hardware (46.99 KB, text/plain)
2017-06-18 18:46 UTC, Malte zu Klampen
Details
alsa-info on asus prime 370 pro (42.06 KB, text/plain)
2018-01-12 11:05 UTC, thomasg
Details
alsa-info of ASUS ROG STRIX X470-F GAMING (59.92 KB, text/plain)
2018-10-18 00:29 UTC, aeder.redea
Details
ALSA INFO ASUS ROG X370-F Gaming (69.78 KB, text/plain)
2018-10-24 11:15 UTC, Sebastian Hofmann
Details
alsa-info of ASUS ROG Crosshair VI Hero Wifi (ALC1220) (53.14 KB, text/plain)
2018-11-21 13:46 UTC, evilphish
Details
alsa-info of ASUS ROG STRIX X470-F GAMING (58.06 KB, text/plain)
2019-03-08 17:53 UTC, Rafael Rossi
Details
alsa-info of MSI MEG X399 CREATION (61.72 KB, text/plain)
2019-03-09 11:48 UTC, daxcore
Details
PulseAudio log with loopback module (22.18 KB, text/plain)
2019-04-22 11:19 UTC, Marco
Details
Alsainfo of Gigabyte B450 Aorus Elite (72.19 KB, text/plain)
2019-06-08 11:51 UTC, Marco
Details
VFIO trace of a problematic ALC892 on Windows VM (217.15 KB, text/plain)
2019-06-10 10:46 UTC, Marco
Details
VFIO log on linux after a reboot (codec in cold state) (128.33 KB, text/plain)
2019-06-11 10:33 UTC, Marco
Details
PCI raw commands sent by Windows to the audio codec (7.90 KB, text/plain)
2019-06-22 15:33 UTC, Marco
Details
PCI raw commands sent by Linux to the audio codec (5.95 KB, text/plain)
2019-06-22 15:33 UTC, Marco
Details
linux pci data translated (43.00 KB, text/plain)
2019-07-07 17:13 UTC, Anders
Details
winn pci data translated (43.00 KB, text/plain)
2019-07-07 17:13 UTC, Anders
Details
linuxdecoded (32.82 KB, text/plain)
2019-07-07 20:01 UTC, Anders
Details
windecoded (43.00 KB, text/plain)
2019-07-07 20:02 UTC, Anders
Details
alsa-info now completely ignores my PCI audio cards (5.73 KB, text/plain)
2019-07-11 07:09 UTC, Marco
Details
alsa-info on MSI X370 Krait Gaming (MS-7A33) (51.61 KB, text/plain)
2019-07-11 20:56 UTC, João O.
Details
alsa-info on MSI B450 TOMAHAWK (with Realtek ALC892) (56.96 KB, text/plain)
2019-07-12 13:37 UTC, Alex
Details
1022 1457 patch (723 bytes, patch)
2019-07-25 10:07 UTC, Ernst Sjöstrand
Details | Diff
A test patch for PCI 1022:1457 (3.00 KB, patch)
2019-07-25 14:56 UTC, Takashi Iwai
Details | Diff
Test patch with all DCAPS enabled for 1022:1457 (992 bytes, patch)
2019-08-02 10:57 UTC, Marco
Details | Diff
Kernel Bug reported when trying to access VIA register on a AMD platform (3.67 KB, text/plain)
2019-08-02 16:35 UTC, Marco
Details
A patch to show the fifo size (1.03 KB, patch)
2019-08-02 17:15 UTC, Takashi Iwai
Details | Diff
FIFO sizes from a AMD chipset (1.69 KB, text/plain)
2019-08-02 17:46 UTC, Marco
Details
Test fix patch no.1 (1.48 KB, patch)
2019-08-02 18:28 UTC, Takashi Iwai
Details | Diff
Test fix patch no.2 (4.04 KB, patch)
2019-08-02 18:28 UTC, Takashi Iwai
Details | Diff
Test fix patch no.3 (2.32 KB, patch)
2019-08-03 07:07 UTC, Takashi Iwai
Details | Diff
Test fix patch (revised) (4.53 KB, patch)
2019-08-03 07:43 UTC, Takashi Iwai
Details | Diff
Test fis patch no.5 (4.77 KB, patch)
2019-08-03 08:34 UTC, Takashi Iwai
Details | Diff
pulseaudio log without tsched=0 when acquiring audio (356.01 KB, text/plain)
2019-08-03 20:13 UTC, Marco
Details
My default.pa config file from pulseaudio (4.86 KB, text/plain)
2019-08-03 20:14 UTC, Marco
Details
Test fix patch no.6 (5.05 KB, patch)
2019-08-04 06:32 UTC, Takashi Iwai
Details | Diff
The correct no.6 test patch (5.10 KB, patch)
2019-08-04 06:35 UTC, Takashi Iwai
Details | Diff
Codec trace for the audio output delay problem (5.28 KB, text/plain)
2019-08-04 18:29 UTC, Marco
Details
hda_controller trace from the timing issue of my ALC892 (402.29 KB, application/gzip)
2019-08-06 09:44 UTC, Marco
Details
Patch to remove stream sync calls (1.42 KB, patch)
2019-08-06 10:40 UTC, Takashi Iwai
Details | Diff
Test fix patch no.7 (5.60 KB, patch)
2019-08-06 13:46 UTC, Takashi Iwai
Details | Diff
The partial revert patch (1.81 KB, patch)
2021-03-08 16:07 UTC, Takashi Iwai
Details | Diff
script to adapt alc3234 codec coefs (321 bytes, text/plain)
2023-05-25 12:12 UTC, haro41
Details
patch_realtek_alc1220_record.diff (1.66 KB, application/octet-stream)
2023-05-29 10:35 UTC, pshou
Details

Description icebalm 2017-04-09 18:55:48 UTC
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.
Comment 1 Malte zu Klampen 2017-06-18 18:46:14 UTC
Created attachment 257067 [details]
alsa-info of offending hardware
Comment 2 Malte zu Klampen 2017-06-18 18:52:22 UTC
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.
Comment 3 Luke Ricciolo 2017-08-12 08:24:35 UTC
Same problem, audio microphone capture results a little crackling/noisy kernel 4.12.5

 description: Motherboard
       product: CROSSHAIR VI HERO
       vendor: ASUSTeK COMPUTER INC.

Codec: Realtek ALC1220
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec1220
Subsystem Id: 0x10438735
Revision Id: 0x100003

!!Kernel Information
!!------------------

Kernel release:    4.12.5-041205-generic
Operating System:  GNU/Linux
Architecture:      x86_64
Processor:         x86_64
SMP Enabled:       Yes


!!ALSA Version
!!------------

Driver version:     k4.12.5-041205-generic
Library version:    1.1.0
Utilities version:  1.1.0


!!Loaded ALSA modules
!!-------------------

snd_hda_intel
snd_hda_intel
Comment 4 Luke Ricciolo 2017-08-12 08:51:14 UTC
The same on 4.12.6 and previous, just tried.
Comment 5 Frédéric Pierret 2017-09-06 12:08:49 UTC
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.
Comment 6 Luke Ricciolo 2017-09-07 10:39:56 UTC
I have Asus CrossHair VI Hero ALC1220, but when I boot first on Windows 7 and after on Linux the sound registered from my microphone is still noise/crackling.

So I don't notice the same behavior of your audio device. Sorry.
Comment 7 Luke Ricciolo 2017-09-07 11:39:39 UTC
@Frédéric Pierret: Just for fun I tried your script as is, with your values. 
And after the script run, my mic is still noisy/crackling and my front headset input on my case do not works anymore.

By the way before that I exported my infos_bad file if you need it, but unfortunately I can't have an infos_good one to compare.
Comment 8 Frédéric Pierret 2017-09-07 11:50:19 UTC
(In reply to Luke Ricciolo from comment #7)
> @Frédéric Pierret: Just for fun I tried your script as is, with your values. 
> And after the script run, my mic is still noisy/crackling and my front
> headset input on my case do not works anymore.
> 
> By the way before that I exported my infos_bad file if you need it, but
> unfortunately I can't have an infos_good one to compare.

Sorry if it does not work. Maybe it more related to the input than the output. Maybe you can try to extract relevant information in the diff.
Comment 9 thomasg 2018-01-12 11:05:08 UTC
Created attachment 273555 [details]
alsa-info on asus prime 370 pro

I'm having exactly the same issues with the ALC1220 on another Asus Board, the Prime X370 Pro.
Attached is my alsa-info with coefficients as well.
Kernel is 4.14.12
Comment 10 Artem Hluvchynskyi 2018-01-27 16:36:44 UTC
(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 Frédéric,

I have exactly the same issue with my X370 Gaming K4 too, only with the output though, no sure about input as I don't have a non-USB mic to test. So far I've been working around it by rebooting to Windows 10 and back until finding this. Your script fixes it for me, thank you!

The coeffs are almost the same (which is no wonder with the same MB), except there's no difference in the last one (0x67) so I removed it from the script. Would be great to have it fixed on the driver level though.

So coeff arrays look like this for me:
coeffs=($(echo 0x{16,43,44,5d,5e,63}))
values=($(echo 0x{8020,3405,fa10,0606,0000,e430}))

Thanks again! Now I don't have to reboot to Windows just for this until there's a driver fix :)
Comment 11 Frédéric Pierret 2018-01-27 16:48:44 UTC
(In reply to Artem Hluvchynskyi from comment #10)
> (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 Frédéric,
> 
> I have exactly the same issue with my X370 Gaming K4 too, only with the
> output though, no sure about input as I don't have a non-USB mic to test. So
> far I've been working around it by rebooting to Windows 10 and back until
> finding this. Your script fixes it for me, thank you!
> 
> The coeffs are almost the same (which is no wonder with the same MB), except
> there's no difference in the last one (0x67) so I removed it from the
> script. Would be great to have it fixed on the driver level though.
> 
> So coeff arrays look like this for me:
> coeffs=($(echo 0x{16,43,44,5d,5e,63}))
> values=($(echo 0x{8020,3405,fa10,0606,0000,e430}))
> 
> Thanks again! Now I don't have to reboot to Windows just for this until
> there's a driver fix :)

Thank you for your feedback. I know that there is some work done around these audio chipsets in kernel-4.15 which should probably be backported to kernel-4.14. I will look to it closer when the kernel-4.15 will be released. Have fun ;)
Comment 12 henk717 2018-10-07 22:31:16 UTC
Having the same issue on the MSI X370 Gaming Pro Carbon using the latest 4.18 kernel in all tested distributions, audio is fine but the microphone is having weird behavior that differs depending on configuration.

When audacity is launched it will trigger the bug that increases the recording speed to be insanely high pitched and fast. Prior to using audacity i will hear a robotic noise while speaking that is also present as a robotic echo.

Making use of the tsched=0 the robotic distortion is gone but replaced with severe crackling that over time becomes less severe when for example Discord is launched but still is very notable.

The following is an export of the alsa source.

    index: 1
 name: <alsa_input.pci-0000_21_00.3.analog-stereo>
 driver: <module-alsa-card.c>
 flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
 state: RUNNING
 suspend cause:
 priority: 9039
 volume: front-left: 32768 / 50% / -18,06 dB, front-right: 32768 / 50% / -18,06 dB
         balance 0,00
 base volume: 6554 / 10% / -60,00 dB
 volume steps: 65537
 muted: no
 current latency: 0,22 ms
 max rewind: 0 KiB
 sample spec: s16le 2ch 48000Hz
 channel map: front-left,front-right
              Stereo
 used by: 1
 linked by: 1
 configured latency: 2,50 ms; range is 0,50 .. 1837,33 ms
 card: 1 <alsa_card.pci-0000_21_00.3>
 module: 8
 properties:
  alsa.resolution_bits = "16"
  device.api = "alsa"
  device.class = "sound"
  alsa.class = "generic"
  alsa.subclass = "generic-mix"
  alsa.name = "ALC1220 Analog"
  alsa.id = "ALC1220 Analog"
  alsa.subdevice = "0"
  alsa.subdevice_name = "subdevice #0"
  alsa.device = "0"
  alsa.card = "1"
  alsa.card_name = "HD-Audio Generic"
  alsa.long_card_name = "HD-Audio Generic at 0xfe900000 irq 64"
  alsa.driver_name = "snd_hda_intel"
  device.bus_path = "pci-0000:21:00.3"
  sysfs.path = "/devices/pci0000:00/0000:00:08.1/0000:21:00.3/sound/card1"
  device.bus = "pci"
  device.vendor.id = "1022"
  device.vendor.name = "Advanced Micro Devices, Inc. [AMD]"
  device.product.id = "1457"
  device.product.name = "Family 17h (Models 00h-0fh) HD Audio Controller"
  device.string = "front:1"
  device.buffering.buffer_size = "352768"
  device.buffering.fragment_size = "176384"
  device.access_mode = "mmap+timer"
  device.profile.name = "analog-stereo"
  device.profile.description = "Analog Stereo"
  device.description = "Family 17h (Models 00h-0fh) HD Audio Controller Analog Stereo"
  alsa.mixer_name = "Realtek ALC1220"
  alsa.components = "HDA:10ec1220,1462da32,00100003"
  module-udev-detect.discovered = "1"
  device.icon_name = "audio-card-pci"
 ports:
  analog-input-front-mic: Front Microphone (priority 8500, latency offset 0 usec, available: yes)
   properties:
    device.icon_name = "audio-input-microphone"
  analog-input-rear-mic: Rear Microphone (priority 8200, latency offset 0 usec, available: no)
   properties:
    device.icon_name = "audio-input-microphone"
  analog-input-linein: Line In (priority 8100, latency offset 0 usec, available: no)
   properties:

Very notable here is the buffer size which seems to fall short when comparing it to other audio devices.
Comment 13 aeder.redea 2018-10-18 00:27:55 UTC
I have the same issue on a ASUS ROG STRIX X470-F GAMING motherboard. Killing Pulseaudio while recording on Audacity makes recording work normally, but for obvious reasons this isn't a real solution.
Comment 14 aeder.redea 2018-10-18 00:29:27 UTC
Created attachment 279083 [details]
alsa-info of ASUS ROG STRIX X470-F GAMING
Comment 15 Sebastian Hofmann 2018-10-24 11:14:52 UTC
I have the ASUS ROG STRIX X370-F GAMING and i also have a problem with distorted / crackling output. I also noticed the right channel of my headset is perfect and left channel has crackling and sometimes after reboot theres a noise.

I append my alsainfo and hope it can help to fix the issue.
Comment 16 Sebastian Hofmann 2018-10-24 11:15:53 UTC
Created attachment 279131 [details]
ALSA INFO ASUS ROG X370-F Gaming
Comment 17 Luca Osvaldo M. 2018-11-01 19:19:15 UTC
Getting the same on ALC892, the sound is robotic and distorted on high volume especially.
Comment 18 Axel 2018-11-14 17:01:39 UTC
I can confirm this bug on kernel 4.18 with gigabyte x470 aorus mainboard. The patch from Frédéric did not help me. Without timer-based scheduling and increased default-fragment-size-msec (see https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Glitches.2C_skips_or_crackling) it is a little bit better. I wonder why there are no more reports on this considering how widespread the alc1220 chip is on desktop mainboards.
Comment 19 Parker H 2018-11-16 05:11:17 UTC
I also have this bug on 4.18.16 ArchLinux. I have had the problem ever since I got this board (Taichi X370) and it does get worse the higher the volume. It is bearable for my friends on discord and in game when I turn it down to ~20% but still sounds crackly. They mention it every couple of days but there's nothing I have been able to do about it.
Comment 20 Marten 2018-11-16 11:32:39 UTC
I have the same issue with an Gigabyte GA-AX370-Gaming K3 (ALC1220) on Kubuntu 18.04 with all sorts of Kernels tested.
Comment 21 evilphish 2018-11-21 13:42:13 UTC
Same issue with an Asus ROG Crosshair VI Hero WiFi (ALC1220) running Mint 19 with the 4.19.3 Kernel from the Ubuntu Mainline PPA.

Playback works, recording cackles with static (this also gets worse if another software is playing something back, i.e. running mumble together with a game), and starting Audacity results in the previously described high pitch bug that needs a reboot to clear.
Comment 22 evilphish 2018-11-21 13:46:08 UTC
Created attachment 279567 [details]
alsa-info of ASUS ROG Crosshair VI Hero Wifi (ALC1220)
Comment 23 Tomasz Pieczerak 2018-12-19 22:26:14 UTC
I have the same issue with Gigabyte B450 AORUS PRO (ALC1220) on Ubuntu 18.04.1 LTS and kernel 4.15.0 (default).

Playback work well, recording crackles. I tried Frédéric's script fixing coeffs - most of these values were different indeed - but it doesn't help.
Comment 24 ben.schaaf 2018-12-28 08:29:21 UTC
I have the same issue with Asus PRIME B350-Plus (ALC887-VD) on Ubuntu 18.04.1 and kernels 4.15.0 and 4.20. Playback works perfectly but recording has crackles. tsched=0 and default-fragment-size-msec = 80 improve things but doesn't fix it. Using a USB sound card is the only workaround that's worked so far.
Comment 25 Luca Osvaldo M. 2018-12-28 10:21:55 UTC
Just to point out, could it be something else? Since some people are having the exact issue on other codecs like me on ALC892 the only thing in common is the AMD chipset and CPU
Comment 26 spychodelics 2019-01-02 20:44:23 UTC
Same problem on an Asus X470 Prime with an ALC1220. 

alsa_info here:

http://www.alsa-project.org/db/?f=51d2767bf8486796b87abc616308089588ff2e43
Comment 27 Luca Osvaldo M. 2019-01-03 23:19:23 UTC
For ALC892...

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
Comment 28 Parker H 2019-01-07 04:21:06 UTC
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.
Comment 29 Parker H 2019-01-07 04:36:55 UTC
So it seems this would be a problem with resampling with pulseaudio on certain hardware then? Would that be correct?
Comment 30 Luca Osvaldo M. 2019-01-08 17:27:00 UTC
Hi parker, this does seem to apply even on my ALC887! 

Very nice!

Is there any way to force this on every programs though as a temporary workaround?
Comment 31 Parker H 2019-01-08 17:54:48 UTC
(In reply to Luca from comment #30)
> Hi parker, this does seem to apply even on my ALC887! 
> 
> Very nice!
> 
> Is there any way to force this on every programs though as a temporary
> workaround?

If there is one, I haven't found it. I'm guessing the sampling rate is determined by the program and, if the program does not have an option to change it, you cannot change it.
Comment 32 thomasg 2019-01-08 23:00:53 UTC
I have tried different sampling rates as well, and also tried with plain alsa (w/o pulseaudio), and while it changes the noise characteristics somewhat, it doesn't eliminate or reasonably mitigate them for me.
That's a ASUS PRIME X370 Pro with ALC1220.

This too might be explained by incorrect coefficients in the firmware (for example, the X370 Taichi might use correct ones for one sample rate and incorrect ones for other rates).

I'd still be interested in the Coeffs from someone who owns a copy of windows and can try the warm-restart workaround.
Comment 33 Luca Osvaldo M. 2019-01-08 23:12:23 UTC
tried to set the default-sample-rate=48000 parameter to daemon.conf as well as alternate-sample-rate with the same value, plus default-sample-format = s16le
and an /etc/asound.conf with 

pcm.!default{
        format S16_LE
        rate 48000
        type hw
        card 1
        device 0
}

pcm.!default{
    type plug
    slave.pcm "default"
}
                                                                                                                                      

And it seems to my friends in Discord that the microphone sound quality improved a bit, however when hearing myself with chrome using sites like webcammictest.com I can still clearly hear it.

However when recording with arecord using -D pulse, doesn't have that much noise on it, but when I'm connected on a voice channel on discord or the webcammictest page enabled, the recording (not the same as before, another recording made at the moment basically) would have a lot more crackles on it, and know that I think about it it's pretty similar to the "first minute audio crackling output when entering a discord voice channel" instead, which doesn't happen only when tsched=0 is present in default.pa, I removed it recently when I applied the latest attempts I said before, because with tsched=0 games would have delayed audio.

Are those two bugs related? Before acknowledging the microphone bug issue, on Discord I always had that issue since it's release on Linux.
Still it's strange as I can hear that crackling from everywhere, like if I'm watching a video while entering a voice channel on Discord, basically every audio output I hear with my headphones is distorted in that amount of time, not just one program, the microphone would still have that horrible sound though.
The crackling is definitely similar, obviously the tsched=0 "workaround" doesn't fix the microphone from crackling but fixes the audio output.
 

Obviously, still this happens only on this machine, no problems on my laptop.


Anyway I got Windows, but I tried that a single time some weeks ago but found no difference, I would definitely try that again. 
Should I revert every setting I made on alsa, pulse, etc? 
I often reboot from Windows to Linux too but the noise would still be there so the warm-restart doesn't quite work on me
Comment 34 Parker H 2019-01-09 17:35:19 UTC
Does anyone else also have an issue with communication programs like Discord where it sounds awful and has a delayed echo that sounds a little bit better? This only goes away for me with tsched=0. I had this problem a while ago but I fixed it with tsched=0 and forgot about it. I wonder if it is related? Still have not found a complete work around.
Comment 35 Luca Osvaldo M. 2019-01-10 11:52:08 UTC
Yes I said that right before...
Comment 36 Wojnar 2019-01-10 20:43:43 UTC
(In reply to Parker H from comment #34)
> Does anyone else also have an issue with communication programs like Discord
> where it sounds awful and has a delayed echo that sounds a little bit
> better? This only goes away for me with tsched=0. I had this problem a while
> ago but I fixed it with tsched=0 and forgot about it. I wonder if it is
> related? Still have not found a complete work around.

Yeah, Discord/TS3 or every recording software. For me tsched=0 doesn't work too. Tried plenty of solutions and I'm considering buying external sound card.
Comment 37 Parker H 2019-01-18 02:43:36 UTC
I'm about to just give up and buy a USB sound adapter. Anyone have any news on this?
Comment 38 Luca Osvaldo M. 2019-01-18 11:14:22 UTC
I just have up and bought a new sound card, solves ever problem I had with this chipset.
Buy the good ones from around 10$/€ if you listen to some music.
Comment 39 George Gibbs 2019-01-22 07:28:06 UTC
I'm able to duplicate this on 4.20. Probably just going to pick up a USB solution to bypass it as (other than booting Windows) I haven't been able to find a good workaround for this.
Comment 40 Anders 2019-01-30 17:02:08 UTC
(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.

For my asus prime pro x370 I got these parameters and it seems to work ok with no noise

#!/bin/bash

coeffs=($(echo 0x{5d,5e,5f,63}))
values=($(echo 0x{606,0,a3c1,e430}))

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

Linux 4.18.0-13-generic #14-Ubuntu SMP Wed Dec 5 09:04:24 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Comment 41 Rafael Rossi 2019-03-08 17:52:04 UTC
Same issue here with Asus ROG Strix X470-F with a Ryzen 2 2700.


Also adding that the audio playback is unstable. It get's distorted from time to time.

alsa-info:
http://alsa-project.org/db/?f=c26153ec75a8e3c177abcbaa58e998fd6fa6407f
Comment 42 Rafael Rossi 2019-03-08 17:53:55 UTC
Created attachment 281641 [details]
alsa-info of ASUS ROG STRIX X470-F GAMING
Comment 43 daxcore 2019-03-09 11:48:58 UTC
Created attachment 281661 [details]
alsa-info of MSI MEG X399 CREATION

same issue on MSI MEG X399 CREATION with ALC1220.
Comment 44 wtravisjones 2019-03-15 02:40:10 UTC
Same issue on ASRock B450 Gaming-ITX/ac

No amount of pulseaudio fiddling fixes it. Going to try a usb adapter soon.

http://alsa-project.org/db/?f=32e943a4728b3d94fb771ac9db53accfe6ac1f17

OS: Ubuntu 18.04.2 LTS x86_64 
Kernel: 4.18.0-16-generic 
Uptime: 2 hours, 25 mins 
Packages: 2148 
Shell: bash 4.4.19 
Resolution: 1920x1200, 1920x1200 
DE: GNOME 3.28.3 
WM: GNOME Shell 
WM Theme: Adwaita 
Theme: Ambiance [GTK2/3] 
Icons: Ubuntu-mono-dark [GTK2/3] 
Terminal: gnome-terminal 
CPU: AMD Ryzen 5 2600X (12) @ 3.600GHz
Comment 45 ZigZag 2019-04-07 07:42:01 UTC
I got the same issue with the ASUS ROG Strix B450-F, I'm on the latest Antergos release as a new install with KDE.
Any updates to this issue?
Comment 46 Anders 2019-04-07 08:02:11 UTC
Feels like no, best way to get sound to work seems to be to boot windows first for correct setup of hardware and then reboot in linux.
Comment 47 ZigZag 2019-04-07 12:15:48 UTC
Thanks for the reply Anders

Well I just tried with windows, and it did not work. I guess the only solution to this is buying a separate sound card or some USB dongle.
This is going to be quite a bigger problem, as soon more people buy mb with these chipsets.
Comment 48 George Gibbs 2019-04-07 12:24:17 UTC
(In reply to ZigZag from comment #47)
> Thanks for the reply Anders
> 
> Well I just tried with windows, and it did not work. I guess the only
> solution to this is buying a separate sound card or some USB dongle.
> This is going to be quite a bigger problem, as soon more people buy mb with
> these chipsets.

I try not to go too far off topic in bug threads, but I'll confirm that I ended up giving up and buying a USB adapter. Works fine, which if nothing else confirms that it's just the chipset and not my overall ALSA/Pulse setup or something.

I'm on an Asus ROG Crosshair VI Hero and booting Windows first did not help with mine either.
Comment 49 Luca Osvaldo M. 2019-04-07 12:29:37 UTC
Hi, I ended up buying an external USB sound card too

BTW, just for letting you know, I opened a bug on the pulseaudio tracker too


https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/656
Comment 50 ZigZag 2019-04-08 13:21:55 UTC
Thanks for the reply, I did buy a USB sound card and it worked right out of the box, great to have a solution.
Luca thank you for creating a bug report on the pulseaudio tracker.
I hope this gets fixed soon, for all the other people running in to this issue.
Comment 51 Marco 2019-04-19 12:43:21 UTC
Same problem with a B450 chipset and a ALC892 on a B450 AORUS ELITE motherboard from Gigabyte.
Comment 52 henk717 2019-04-19 14:00:58 UTC
I have been playing around with the ALC1220 again today, I managed to get a pretty clear recording in Audacity going by killing pulseaudio and then reloading the snd-hda-intel module. While not perfect the first second the audio later on is very stable with barely any crackles and the slight crackles I can hear are a lot less loud than before.

It leads me to believe that while the behavior is odd the bug may be inside pulseaudio itself rather then the Kernel but i lack the expertise to confirm or deny this.
Comment 53 Marco 2019-04-19 15:05:31 UTC
(In reply to henk717 from comment #52)
> I have been playing around with the ALC1220 again today, I managed to get a
> pretty clear recording in Audacity going by killing pulseaudio and then
> reloading the snd-hda-intel module. While not perfect the first second the
> audio later on is very stable with barely any crackles and the slight
> crackles I can hear are a lot less loud than before.
> 
> It leads me to believe that while the behavior is odd the bug may be inside
> pulseaudio itself rather then the Kernel but i lack the expertise to confirm
> or deny this.

Yes, it seems a little less prominent, but at least on my side it is still quite present. It seems to be dependent from the actual signal coming from the microphone, if there is not any signal coming in it's barely present; as soon as you start speaking, it scales accordingly.

Luckily i've an old USB to dual jack adapter laying around, but it's not an ideal solution for me.
Comment 54 thomasg 2019-04-19 19:12:22 UTC
I, too, tried without pulseaudio and plain alsa, and too noticed, that the noise is different (in a way that makes it slightly less annoying).
This however does not mean, that eliminating pulseaudio eliminates the noise issues, pulseaudios parameters just make the noise profile seem a little worse.

In any case, the quality without pulseaudio is still unacceptably horrible and I would never make anyone else listen to audio captured with said noise willingly.
This clearly is not a pulseaudio issue.
Comment 55 Marco 2019-04-22 11:15:43 UTC
(In reply to thomasg from comment #54)
> I, too, tried without pulseaudio and plain alsa, and too noticed, that the
> noise is different (in a way that makes it slightly less annoying).
> This however does not mean, that eliminating pulseaudio eliminates the noise
> issues, pulseaudios parameters just make the noise profile seem a little
> worse.
> 
> In any case, the quality without pulseaudio is still unacceptably horrible
> and I would never make anyone else listen to audio captured with said noise
> willingly.
> This clearly is not a pulseaudio issue.

Yea, even to me this looks more like an ALSA driver bug more than a pulseaudio one.

Still, for curiosity, I've run pulseaudio from a terminal with log enabled and inserted the loopback module to test if the actual noise coming from the microphone was triggering something inside pulseaudio, but as far as I can see I don't see any problem in it.

I'll attach it here hoping that it will help narrow down this bug. I've tried to search how to have a log from ALSA, I found something setting flag in the kernel, enabled it passing parameters to the correct audio codec but I don't see how to actually get it, since dmesg doesen't show anything from ALSA when microphone is running.
Comment 56 Marco 2019-04-22 11:19:22 UTC
Created attachment 282449 [details]
PulseAudio log with loopback module

Log from pulseaudio -vvvv of my ALC892 loading and unloading after 30 seconds the loopback module
Comment 57 Marco 2019-04-24 13:53:10 UTC
Just tested OSS, unfortunately while I found the codec inside the driver that I have in my system, the driver doesn't load the HDA module. Even modprobing it doesn't show anything in the audio devices.

Ironically I have the same codec (ALC892) on an older 4th gen Intel chipset (HM87, if I recall correctly) on a laptop, and there the acquisition work flawlessly, no stutter or anything else (with ALSA).

I hope that it will be fixed eventually, sooner or later.
Comment 58 Marco 2019-04-26 12:33:24 UTC
Using arecord still trigger the cracking sound (and according to the manpage, this program records directly from ALSA). However, using Audacity and manually selected the audio acquisition device coming from the ALSA driver and not the audio from PulseAudio, that have the same problems of the rest of the software. Result = clean and crispy sound (with PulseAudio still running in background). Before trying that I've stupidly tried to play with all the parameters from the exposed hda driver, to no avail. Dumped the pinconfigs from Windows, and compared to the ones set by Linux, to see if there was any additional parameters passed to the HDA controller that was fixing the problem. Nothing.

I'll assume that the problem lies in PulseAudio and not ALSA (even if I can't explain to myself why arecord still have the same problem through ALSA and not Audacity). Unfortunately, a lot of software on Linux can't speak directly through ALSA, so I'm stuck for now.
Comment 59 Marco 2019-04-26 14:12:53 UTC
After some testing with the PulseAudio folks, they have determined that the bugs relies on ALSA, just FYI.
Comment 60 Axel 2019-04-27 07:56:09 UTC
Since this bug is open for over two years and there was no response from any developer I'm asking myself if we should also send a report or a reminder of this bug to one of the kernel / sound subsystem mailing lists. Did anyone already do this?
Comment 61 Marco 2019-04-27 08:26:09 UTC
(In reply to Axel from comment #60)
> Since this bug is open for over two years and there was no response from any
> developer I'm asking myself if we should also send a report or a reminder of
> this bug to one of the kernel / sound subsystem mailing lists. Did anyone
> already do this?

Tried on alsa-info yesterday, linking the two bug report in kernel for ALC892 and ALC1220 here. For now, no response yet. Maybe try to find someone from ALSA on irc to see if debugging it live can finally fix the problem?
Comment 62 Marco 2019-04-27 08:28:05 UTC
*alsa-user, sorry.
Comment 63 Luca Osvaldo M. 2019-04-27 13:56:43 UTC
https://github.com/torvalds/linux/blob/34396bdfd2b7b41b9dcd2126eb1a57e43fe13368/sound/pci/hda/patch_realtek.c

There it is the kernel part related for ALC codecs (or it should be) and it's copyrighted by 
* Kailang Yang        <kailang@realtek.com.tw>
 *                    PeiSen Hou <pshou@realtek.com.tw>
 *                    Takashi Iwai <tiwai@suse.de>
 *                    Jonathan Woithe <jwoithe@just42.net>

Are they already in this mailing list?
Comment 64 Marco 2019-04-27 14:22:36 UTC
Yes, that's the patch code from Realtek for their HDA implementation. 
I don't know, unfortunately. Maybe I'll forward to them a CC of the same email to see if they can help us.
Comment 65 Marco 2019-04-27 18:04:01 UTC
(In reply to Luca from comment #63)
> https://github.com/torvalds/linux/blob/
> 34396bdfd2b7b41b9dcd2126eb1a57e43fe13368/sound/pci/hda/patch_realtek.c
> 
> There it is the kernel part related for ALC codecs (or it should be) and
> it's copyrighted by 
> * Kailang Yang        <kailang@realtek.com.tw>
>  *                    PeiSen Hou <pshou@realtek.com.tw>
>  *                    Takashi Iwai <tiwai@suse.de>
>  *                    Jonathan Woithe <jwoithe@just42.net>
> 
> Are they already in this mailing list?

Just tested with 5.0.10, since I saw a bit of commit on ALSA. No dice here.

Sent a CC of the alsa-user to the 4 email, unfortunately the two address from Realtek are not available anymore.
Comment 66 Marco 2019-05-21 16:44:27 UTC
Still present in 5.1.3.
Comment 67 Marco 2019-05-27 09:39:02 UTC
Still present in 5.1.5.
Comment 68 Raveesh Agarwal 2019-05-27 15:01:54 UTC
Hi. I am new to this and I feel I should not have bought the mobo I did (TR4 build).

That said, I just mailed this issue to <pctech@realtek.com>, Realtek's Tech support.
Comment 69 Marco 2019-05-27 16:15:40 UTC
(In reply to Raveesh Agarwal from comment #68)
> Hi. I am new to this and I feel I should not have bought the mobo I did (TR4
> build).
> 
> That said, I just mailed this issue to <pctech@realtek.com>, Realtek's Tech
> support.

I had some back and forth with tiwai, and the suspect is less on the codec and more on the hda host in the chipset from AMD. The problem is that AMD hasn't provided the documentation for their chipset after 2015. I have literally the same codec on an older Intel laptop board, and on that platform the codec works perfectly fine.

Take all of this with a big grain of salt, but the only way to fix this, if it's the host side, is to hope that AMD release their documentation on their site. I've already mailed a month ago to their tech support, but as of today I haven't heard anything from them.
Comment 70 George Gibbs 2019-05-27 19:44:30 UTC
(In reply to Marco from comment #69)
> (In reply to Raveesh Agarwal from comment #68)
> > Hi. I am new to this and I feel I should not have bought the mobo I did
> (TR4
> > build).
> > 
> > That said, I just mailed this issue to <pctech@realtek.com>, Realtek's Tech
> > support.
> 
> I had some back and forth with tiwai, and the suspect is less on the codec
> and more on the hda host in the chipset from AMD. The problem is that AMD
> hasn't provided the documentation for their chipset after 2015. I have
> literally the same codec on an older Intel laptop board, and on that
> platform the codec works perfectly fine.
> 
> Take all of this with a big grain of salt, but the only way to fix this, if
> it's the host side, is to hope that AMD release their documentation on their
> site. I've already mailed a month ago to their tech support, but as of today
> I haven't heard anything from them.

If it is a chipset issue, maybe Asmedia would be the best contact? I believe they were contracted to produce all AM4 chipsets prior to the new 5 series (X570).
Comment 71 Marco 2019-05-28 06:46:50 UTC
(In reply to George Gibbs from comment #70)
> (In reply to Marco from comment #69)
> > (In reply to Raveesh Agarwal from comment #68)
> > > Hi. I am new to this and I feel I should not have bought the mobo I did
> > (TR4
> > > build).
> > > 
> > > That said, I just mailed this issue to <pctech@realtek.com>, Realtek's
> Tech
> > > support.
> > 
> > I had some back and forth with tiwai, and the suspect is less on the codec
> > and more on the hda host in the chipset from AMD. The problem is that AMD
> > hasn't provided the documentation for their chipset after 2015. I have
> > literally the same codec on an older Intel laptop board, and on that
> > platform the codec works perfectly fine.
> > 
> > Take all of this with a big grain of salt, but the only way to fix this, if
> > it's the host side, is to hope that AMD release their documentation on
> their
> > site. I've already mailed a month ago to their tech support, but as of
> today
> > I haven't heard anything from them.
> 
> If it is a chipset issue, maybe Asmedia would be the best contact? I believe
> they were contracted to produce all AM4 chipsets prior to the new 5 series
> (X570).

Might be worth a try. On their site there is a mail for tech support; if someone is willing to contact them regarding this issue please go ahead.
Comment 73 Marco 2019-06-04 17:56:50 UTC
(In reply to Alex Deucher from comment #72)
> Have you tried a kernel which contains these patches?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=9ceace3c9c18c67676e75141032a65a8e01f9a7a
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=1adca4b0cd65c14cb8b8c9c257720385869c3d5f

Yep, this was tried with tiwai with my PCI host controller IDs. Nothing changed, unfortunately.
Comment 74 Marco 2019-06-05 15:46:50 UTC
Still present on 5.1.7. 

Just for the sake of it, I tried playing with the possible quirks offered in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/pci/hda/hda_controller.h?h=v5.1.7
to see if one of them will change something. No dice, the issue is still the same.

Recently, under VFIO and using Scream to pass the audio back to Linux for playback in Pulse (since W1903 broke HDA emulated audio from QEMU, thanks Microsoft), I noticed huge stutters and audio desync while playing games; huge pauses and even a game crash claiming that the GPU was removed (classic video driver crash), followed by something on the lines of a kernel OOPS on dmesg (If i don't remember badly). After trying to use the audio codec integrated inside the GPU and remove the Scream HDA everything was working perfectly fine, no audio stutter, nothing.

I'll try to reproduce that and eventually post it here.

The more I try, the more it appears to me that on these platform the HDA PCI subsystem has serious timing issues with Realtek codecs (unless these issues are present on other codecs), and for some reason this stalls the PCI bus completely, with all the problems that this entails.
Comment 75 Ivan 2019-06-08 11:30:19 UTC
Hi Marco,

Just to back it up, I tried the same things and I'm in the same situation:
ALC1220, [1022:1457] subsys [1458:a0c3] on 5.1.7.

Explored and played around with the snd_hda_intel, especially around
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/pci/hda/hda_intel.c
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/pci/hda/patch_realtek.c

Tried different quirks, including the Gigabyte ones ( dual codec etc. ), with NO LUCK. Explored also with hda_analyzer and played around with the components but not useful.
Wanted to get in contact with tiwai to understand better the module parts, but then i read your comments informing also that it was about the codec part and docs/specs missing from AMD so didn't continue the effort.

Would be interesting to understand if the problem is really about the codec ( feels like ) and who could be contacted to obtain missing info... shouldn't it be realtek related?
Comment 76 Luca Osvaldo M. 2019-06-08 11:32:30 UTC
(In reply to Ivan from comment #75)
> Hi Marco,
> 
> Just to back it up, I tried the same things and I'm in the same situation:
> ALC1220, [1022:1457] subsys [1458:a0c3] on 5.1.7.
> 
> Explored and played around with the snd_hda_intel, especially around
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/
> pci/hda/hda_intel.c
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/
> pci/hda/patch_realtek.c
> 
> Tried different quirks, including the Gigabyte ones ( dual codec etc. ),
> with NO LUCK. Explored also with hda_analyzer and played around with the
> components but not useful.
> Wanted to get in contact with tiwai to understand better the module parts,
> but then i read your comments informing also that it was about the codec
> part and docs/specs missing from AMD so didn't continue the effort.
> 
> Would be interesting to understand if the problem is really about the codec
> ( feels like ) and who could be contacted to obtain missing info...
> shouldn't it be realtek related?


So far I'm absolutely sure it's something related to the AMD platform, since it happens also on other codecs only with AMD chipsets, I got an ALC892 for example and I have the same issue
Comment 77 Marco 2019-06-08 11:45:08 UTC
(In reply to Ivan from comment #75)
> Hi Marco,
> 
> Just to back it up, I tried the same things and I'm in the same situation:
> ALC1220, [1022:1457] subsys [1458:a0c3] on 5.1.7.
> 
> Explored and played around with the snd_hda_intel, especially around
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/
> pci/hda/hda_intel.c
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/sound/
> pci/hda/patch_realtek.c
> 
> Tried different quirks, including the Gigabyte ones ( dual codec etc. ),
> with NO LUCK. Explored also with hda_analyzer and played around with the
> components but not useful.
> Wanted to get in contact with tiwai to understand better the module parts,
> but then i read your comments informing also that it was about the codec
> part and docs/specs missing from AMD so didn't continue the effort.
> 
> Would be interesting to understand if the problem is really about the codec
> ( feels like ) and who could be contacted to obtain missing info...
> shouldn't it be realtek related?

If you look at the alsainfo posted on this thread you will see that all of them has a host side PCI id of 1022:1457, but not on the codec side (I have an ALC892, you an ALC1220, different IDs). As far as I can see this points more on a HDA front end, since it's the only common factor on all the boards. 

The issues reported is only with Realtek codecs; maybe it's a combination of the two (AMD chipset and Realtek codec?), however without trying other boards with the same chipset and a different audio codec we will never know for certain if it's a codec quirk or a HDA chipset one.

Without chipset docs, this will not be easy to fix. I have already sent an email to Asmedia Tech Support (chipset maker for AMD), but I doubt I will ever get an answer.

On an unrelated note, the desync and kernel OOPS on KVM seems to be caused by my preemtible kernel, after disabling it the output was perfectly fine; so this issue wasn't the cause of that.
Comment 78 Marco 2019-06-08 11:51:56 UTC
Created attachment 283153 [details]
Alsainfo of Gigabyte B450 Aorus Elite
Comment 79 Luca Osvaldo M. 2019-06-08 12:56:08 UTC
So could we try getting in touch with the HDA maintainers?
Comment 80 Marco 2019-06-08 13:06:02 UTC
(In reply to Luca from comment #79)
> So could we try getting in touch with the HDA maintainers?

I’ll doubt they will ever be able to fix this issue without specifications. The only way, if you ask me, is to get hold of someone from the chipset manufacturing side, be AMD or Asmedia.
Comment 81 Anders 2019-06-08 13:14:20 UTC
Created attachment 283161 [details]
attachment-26498-0.html

Maybe it would be possible to use a technique similiar to what jcs did to
get sound to work on obsd (https://jcs.org/2018/11/12/vfio)?
// *Anders*


Den lör 8 juni 2019 kl 15:06 skrev <bugzilla-daemon@bugzilla.kernel.org>:

> https://bugzilla.kernel.org/show_bug.cgi?id=195303
>
> --- Comment #80 from Marco (rodomar705@protonmail.com) ---
> (In reply to Luca from comment #79)
> > So could we try getting in touch with the HDA maintainers?
>
> I’ll doubt they will ever be able to fix this issue without
> specifications. The
> only way, if you ask me, is to get hold of someone from the chipset
> manufacturing side, be AMD or Asmedia.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 82 Marco 2019-06-08 13:31:22 UTC
(In reply to Anders from comment #81)
> Created attachment 283161 [details]
> attachment-26498-0.html
> 
> Maybe it would be possible to use a technique similiar to what jcs did to
> get sound to work on obsd (https://jcs.org/2018/11/12/vfio)?
> // *Anders*
> 
> 
> Den lör 8 juni 2019 kl 15:06 skrev <bugzilla-daemon@bugzilla.kernel.org>:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=195303
> >
> > --- Comment #80 from Marco (rodomar705@protonmail.com) ---
> > (In reply to Luca from comment #79)
> > > So could we try getting in touch with the HDA maintainers?
> >
> > I’ll doubt they will ever be able to fix this issue without
> > specifications. The
> > only way, if you ask me, is to get hold of someone from the chipset
> > manufacturing side, be AMD or Asmedia.
> >
> > --
> > You are receiving this mail because:
> > You are on the CC list for the bug.

Nice find. Yes, if the magic resides inside the Realtek drivers.
Comment 83 Marco 2019-06-10 10:45:25 UTC
Ok, update on this issue.

Rebuilt CEMU with the two patches provided above, stubbed out only the audio card (luckily the HDA codec was in its own IOMMU group, so no problem there passing the card to the Windows VM) and tested without any tracing first.

Result: audio working perfectly fine; both microphone and headphone output are working as in Windows bare hardware. So it's a codec issue at this point? If I simply stub out from Linux the audio codec (without reset capabilities, since the first PCI bus to have it accordingly to VFIO is a child of group 19 which is not owned, and it still work after a reboot of the VM).

Regardless, after enabling tracing (from command line, I have tested the card under a clone of my VFIO GPU Windows 10 VM managed by Virtual Machine Manager), the audio stack from Windows wasn't responding anymore (probably cause of the tracing, I suppose? But I wasn't seeing a lot of output anyway; so I'm not so sure about that); This made me unable to enable the microphone under Windows with tracing enabled. Just taken a look to the trace output however, and I can see sensible stuff in that file, like codec IDs and stuff like that.

It's a little big, so I'll replay it on linux to try to find what magic number make the audio codec to work, however I'll post it here hoping that this will finally help Realtek engineers to spot the problem in the missconfiguration? of the codec.

Hope that this will help to finally fix this issue,

Marco
Comment 84 Marco 2019-06-10 10:46:16 UTC
Created attachment 283173 [details]
VFIO trace of a problematic ALC892 on Windows VM
Comment 85 Marco 2019-06-10 17:18:15 UTC
(In reply to Marco from comment #84)
> Created attachment 283173 [details]
> VFIO trace of a problematic ALC892 on Windows VM

I will post shortly a VFIO trace from Linux, as soon as I have the time.
Comment 86 Luca Osvaldo M. 2019-06-10 20:32:27 UTC
I have another info, this is a really odd behaviour.

I don't know if you ever used Discord, I discovered this bug because my friends told me my microphone sounded really bad.

But another thing I noticed, is that when I enter a voice channel, other than the microphone sounding bad, the Desktop becomes really choppy (GNOME) and video playback on Twitch.tv videos is laggy, it frequently loses frames.
CPU Usage not even remotely close to 40% on my 6 core AMD CPU. 

Then, guess what? This DOES NOT happen when using an external USB sound card, which i bought specifically to bypass this bug.
Video playback is fine, the desktop is fine and smooth.

I don't know what's wrong with this buggy audio driver, but it's really something that needs to be figured out by developers...

What the hell how a sound card driver could even mess with the desktop performance? Interrupts?

I don't own a bad iGPU, I got an AMD RX 580 with 8GB of VRAM which should be perfectly capable to handle the desktop.
Comment 87 Marco 2019-06-11 06:48:29 UTC
(In reply to Luca from comment #86)
> I have another info, this is a really odd behaviour.
> 
> I don't know if you ever used Discord, I discovered this bug because my
> friends told me my microphone sounded really bad.
> 
> But another thing I noticed, is that when I enter a voice channel, other
> than the microphone sounding bad, the Desktop becomes really choppy (GNOME)
> and video playback on Twitch.tv videos is laggy, it frequently loses frames.
> CPU Usage not even remotely close to 40% on my 6 core AMD CPU. 
> 
> Then, guess what? This DOES NOT happen when using an external USB sound
> card, which i bought specifically to bypass this bug.
> Video playback is fine, the desktop is fine and smooth.
> 
> I don't know what's wrong with this buggy audio driver, but it's really
> something that needs to be figured out by developers...
> 
> What the hell how a sound card driver could even mess with the desktop
> performance? Interrupts?
> 
> I don't own a bad iGPU, I got an AMD RX 580 with 8GB of VRAM which should be
> perfectly capable to handle the desktop.
Yea, most likely interrupt stalling if you ask me.

Personally, if the capture is enabled in the integrated audio card while discord is enabled, half of the times it begin to randomly loop back the audio from the output for no apparent reason (yes, the loop back interface is disabled in alsamixer).

I honestly haven’t got system stutter globally, and I basically have almost the same hardware as you, Ryzen 2600 + RX580; So I’m not sure as what it can trigger that behaviour. I’m using the integrated only to output audio (since is much better than my USB external audio card).
Comment 88 Marco 2019-06-11 10:33:50 UTC
Created attachment 283191 [details]
VFIO log on linux after a reboot (codec in cold state)
Comment 89 Marco 2019-06-11 10:41:29 UTC
I had also tried to boot Windows, and then afterwards Linux without a codec reset; however the issue is still present. The reverse act exactly the same. On Windows the codec always work fine, on Linux the codec has always the issue, regardless of the precedent state.
Comment 90 Luca Osvaldo M. 2019-06-11 17:11:27 UTC
(In reply to Marco from comment #87)
> (In reply to Luca from comment #86)
> > I have another info, this is a really odd behaviour.
> > 
> > I don't know if you ever used Discord, I discovered this bug because my
> > friends told me my microphone sounded really bad.
> > 
> > But another thing I noticed, is that when I enter a voice channel, other
> > than the microphone sounding bad, the Desktop becomes really choppy (GNOME)
> > and video playback on Twitch.tv videos is laggy, it frequently loses
> frames.
> > CPU Usage not even remotely close to 40% on my 6 core AMD CPU. 
> > 
> > Then, guess what? This DOES NOT happen when using an external USB sound
> > card, which i bought specifically to bypass this bug.
> > Video playback is fine, the desktop is fine and smooth.
> > 
> > I don't know what's wrong with this buggy audio driver, but it's really
> > something that needs to be figured out by developers...
> > 
> > What the hell how a sound card driver could even mess with the desktop
> > performance? Interrupts?
> > 
> > I don't own a bad iGPU, I got an AMD RX 580 with 8GB of VRAM which should
> be
> > perfectly capable to handle the desktop.
> Yea, most likely interrupt stalling if you ask me.
> 
> Personally, if the capture is enabled in the integrated audio card while
> discord is enabled, half of the times it begin to randomly loop back the
> audio from the output for no apparent reason (yes, the loop back interface
> is disabled in alsamixer).
> 
> I honestly haven’t got system stutter globally, and I basically have almost
> the same hardware as you, Ryzen 2600 + RX580; So I’m not sure as what it can
> trigger that behaviour. I’m using the integrated only to output audio (since
> is much better than my USB external audio card).

I'm on a vanilla Ubuntu LTS install trying to keep things as stable as possible, so no I've enabled no Pulseaudio loopback modules...
In alsa is disabled 

With further testing, as long I'm on a discord voice channel with my microphone muted, no stutters at all. The problem begins when the microphone on Discord is recording something.
Of course doesn't happen on my USB audio card
Comment 91 Benjamin Cheng 2019-06-16 19:07:45 UTC
I'm also having the microphone crackling issue on an ASUS Prime x470-pro with a Ryzen 2600 + R9 390X. I can confirm the issue doesn't occur in Windows but with a reboot into Linux the issue is still present for me.

What I've tried with is `arecord` with alsa directly, which yields minimal crackling (https://static.bcheng.me/misc/alsa.wav). With pulse (https://static.bcheng.me/misc/pulse.wav) the crackling is much more apparent. I checked in with the pulseaudio guys and they say this issue is probably rooted in ALSA but pulse exaggerates it.

I'm not sure where to continue with investigating this but I'm happy to help.
Comment 92 Marco 2019-06-19 09:46:59 UTC
I just have compared the codec state with this Windows tool provided from Microsoft: https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn613936(v=vs.85)

The state is exactly identical. I can't see any difference both on pinconfigs and on the widgets caps, inputs or outputs (at least on the input side where the mic pass through, but I doubt they will differ in the outputs)).

I have no clue on why on an operating system is working correctly and another is not, with the same state (at least on the problematic part, but I haven't read the Intel specification, so take it with a big grain of salt); and I don't really know where to proceed from here, besides trying to clean up the PCI trace and try to playing it back to see what happens (which I probably eventually will).

I would post the dump from the tool, but of course it's all binary so without the tool it would be useless anyway.If you need it, just ask.
Comment 93 Marco 2019-06-22 15:32:10 UTC
Update on this again:

After trying the extremely small other open non-Linux distributions, in hope to find more details on the codec, the only partially working implementation tried was the BSDs, the particular version tried by me was FreeBSD. After debugging issues with X non posting on KVM, I managed to boot it up and test their implementation. The problem is also present under FBSD, in a less aggressive manner however. It's almost usable, but it's nowhere near clear as in Windows. Unfortunately, other operating systems either are completely not booting under KVM or simply doesn't support it.

The only option is to compare the commands sent to the codec by Win vs Linux. After writing a regex, I've cleaned the trace leaving simply the raw commands sent by the codec.

The problem lies in the fact that Linux send to the codec approx 6k of commands, while win approx 8k. I can't find a parser online for the HDA specification, and if I have to go step by step with the datasheet by Intel and Realtek, this will take ages, frankly. Diffing the two files doesn't help that much, since the only partial matches are at the beginning of the initialization (and some further down, but it's not really that much).

I'll probably just try to send it as is, but maybe I'll try to reduce the combinations by trying reading the specs.

I'll replace the two previous traces with the new raw commands log, if someone want to take a peek at it.
Comment 94 Marco 2019-06-22 15:33:02 UTC
Created attachment 283389 [details]
PCI raw commands sent by Windows to the audio codec
Comment 95 Marco 2019-06-22 15:33:35 UTC
Created attachment 283391 [details]
PCI raw commands sent by Linux to the audio codec
Comment 96 Luca Osvaldo M. 2019-06-29 13:05:44 UTC
Some reports in the ubuntu bug file suggests this is also happening on old AMD platforms as well... 
With even different ALC codecs.
Comment 97 Jon 2019-07-05 01:13:09 UTC
I'm also experiencing this issue on an MSI B450 Carbon Pro Gaming AC mobo with the ALC1220 codec. I can get the output crackling to stop somewhat using tsched=0, but my mic still experiences the issue.

Works fine in Windows.
Comment 98 icebalm 2019-07-05 02:30:06 UTC
I submitted this bug over 2 years ago. It's pretty obvious at this point that it'll never get fixed. It's a shame all the board makers are using these realtek chips. I'd expect with their popularity some developer somewhere would have wanted it fixed. Do we have to take a collection for a bug bounty for someone to be interested in this? It might end up being cheaper than us all going out and buying USB DACs. Oh, wait, I already bought one.
Comment 99 Léo El Amri 2019-07-05 12:38:21 UTC
Frédéric Pierret was the first here to identify a possible origin for the problem. And Marco did preliminary work on this. The "jcs way" looks promising to me, but surely it requires a lot of work. I'm joining you on the fact that we might never get help from Realtek on this, but I don't think we should disregard community's effort :)

On my side, I also have a Realtek ALC1220 codec
    Codec: Realtek ALC1220
    Vendor Id: 0x10ec1220
    Subsystem Id: 0x18492220
    Revision Id: 0x100101
equipped on an ASRock B450 Gaming-ITX/ac motherboard ("AMD Promontory B450" chipset).
The sound coming out the green jack is OK.
The sound recorded from the microphone plugged on the pink jack is crackling.
I'm running Linux 4.19.44.
Comment 100 Marco 2019-07-05 16:08:41 UTC
(In reply to Léo El Amri from comment #99)
> ...
> And Marco did preliminary work on this. The "jcs way" looks
> promising to me, but surely it requires a lot of work.
> ...

Yea, I'm still trying to find the energy to begin to write a parser for the codec commands, but this will surely take quite a lot of time.

Luckily on the ALC892 datasheets are available online, so even if it is a vendor defined command (assuming they exists, but I think that's the case) from Realtek, we should be able to identify it.

The problem is that I can't find the strength to read ca 120 pages (between vendor and HDA spec) of commands right now and extrapolate a script to parse them :P

Maybe later this year I'll be giving that a shot; but not right now. For now I'm adapting to use an external audio card; at least for voice chat, it's good enough for me.
Comment 101 Benjamin Cheng 2019-07-05 17:00:30 UTC
(In reply to Marco from comment #100)

> Yea, I'm still trying to find the energy to begin to write a parser for the
> codec commands, but this will surely take quite a lot of time.

This actually sounds like something I would be interested in working on. However I don't really have any experience working with low level audio like this.

Are the dumps you gave for the ALC892?
Comment 102 Marco 2019-07-05 17:19:04 UTC
(In reply to Benjamin Cheng from comment #101)
> (In reply to Marco from comment #100)
> 
> > Yea, I'm still trying to find the energy to begin to write a parser for the
> > codec commands, but this will surely take quite a lot of time.
> 
> This actually sounds like something I would be interested in working on.
> However I don't really have any experience working with low level audio like
> this.
> 
> Are the dumps you gave for the ALC892?

Yep, they are coming from my ALC892. If you want to try to create a script to parse them, be my guest :)

The only issue on Windows is that after the dump, the audio stack from Windows wasn’t responding; however that should not be an issue, if it’s simply a state change from the driver at boot up.
Comment 103 Anders 2019-07-07 17:13:13 UTC
Created attachment 283575 [details]
linux pci data translated
Comment 104 Anders 2019-07-07 17:13:50 UTC
Created attachment 283577 [details]
winn pci data translated
Comment 105 Jon 2019-07-07 19:45:59 UTC
Anders, looks like those two files are exactly the same? I think the Linux file didn't get uploaded.
Comment 106 Anders 2019-07-07 20:01:21 UTC
Created attachment 283579 [details]
linuxdecoded
Comment 107 Anders 2019-07-07 20:02:05 UTC
Created attachment 283581 [details]
windecoded
Comment 108 Anders 2019-07-07 20:02:39 UTC
better now?
Comment 109 Marco 2019-07-10 10:02:41 UTC
(In reply to Anders from comment #108)
> better now?

Thanks a lot, now I just need to go back reading the specs :P
Comment 110 Ernst Sjöstrand 2019-07-10 12:38:50 UTC
Should this bug be renamed to something like "Sound capture is crackled with all snd_hda_intel codecs on AM4 platforms"?
Comment 111 Jon 2019-07-10 13:59:06 UTC
Seems to affect playback as well (at least for me unless tsched=0, but even then get weird bugs), probably should be something like this:

snd_hda_intel - Sound input/output is distorted on AM4 platforms using Realtek codecs.
Comment 112 Marco 2019-07-10 14:41:54 UTC
(In reply to Jon from comment #111)
> Seems to affect playback as well (at least for me unless tsched=0, but even
> then get weird bugs), probably should be something like this:
> 
> snd_hda_intel - Sound input/output is distorted on AM4 platforms using
> Realtek codecs.

This seems more in line with the problems in this thread, to me.
Comment 113 Léo El Amri 2019-07-10 18:10:58 UTC
I was wondering about this as well. It looks like not everyone have the exact same issue. For example, I have problems with sound input only while other people reported sound problem with output as well.

I tried to gather and resume the reports given until now. I hope I didn't made a mistake. The values "Yes", "No" and '"Same"' in the "Input" and "Output" columns means "Does have the issue", "Does not have the issue" and 'Reported "the same problem"' respectively.

Reporter           Input  Output Codec     Motherboard
================== =====  ====== ========= ====================================
icebalm[...]       Yes    No     ALC1220   ASUS CROSSHAIR VI HERO
Malte zu Klampen   "Same" "Same" ?         ASUS PRIME X370-PRO
Luke Ricciolo      Yes    "Same" ALC1220   ASUS CROSSHAIR VI HERO
Frédéric Pierret   "Same" "Same" ALC1220   ASROCK X370 GAMING K4
thomasg            "Same" "Same" ALC1220   ASUS PRIME X370-PRO
Artem Hluvchynskyi ?      Yes    ALC1220   ASROCK X370 GAMING K4
henk717[...]       Yes    No     ALC1220   MSI X370 Gaming Pro Carbon
aeder.redea[...]   Yes    No     ALC1220   ASUS ROG STRIX X470-F GAMING
Sebastian Hofmann  ?      Yes    ALC1220   ASUS ROG STRIX X370-F GAMING
Luca               "Same" "Same" ALC892    ?
Axel               "Same" "Same" ?         Gigabyte X470 AORUS
Parker H           "Same" "Same" ?         Taichi X370
Marten             "Same" "Same" ALC1220   Gigabyte GA-AX370-Gaming K3
evilphish[...]     Yes    No     ALC1220   ASUS ROG CROSSHAIR VI HERO WiFi
Tomasz Pieczerak   Yes    No     ALC1220   Gigabyte B450 AORUS PRO
ben.schaaf[...]    Yes    No     ALC887-VD ASUS PRIME B350-Plus
spychodelics[...]  "Same" "Same" ALC1220   ASUS PRIME X470-PRO
Anders             ?      ?      ?         ASUS PRIME X370-PRO
Rafael Rossi       Yes    Yes    ALC1220   ASUS ROG STRIX X470-F GAMING
daxcore[...]       "Same" "Same" ALC1220   Micro-Star MEG X399 CREATION MS-7B92
wtravisjones[...]  "Same" "Same" ALC1220   ASRock B450 Gaming-ITX/ac
ZigZag             "Same" "Same" ?         ASUS ROG Strix B450-F
George Gibbs       "Same" "Same" ?         ASUS ROG CROSSHAIR VI HERO
Marco              "Same" "Same" ALC892    Gigabyte B450 AORUS ELITE
Benjamin Cheng     Yes    ?      ?         ASUS PRIME X470-PRO
Jon                "Same" Yes    ALC1220   MSI B450 Carbon Pro Gaming AC
Léo El Amri        Yes    No     ALC1220   ASRock B450 Gaming-ITX/ac
Comment 114 Marco 2019-07-11 07:05:58 UTC
Well, another update that probably will be the last one from me, since I'm beginning to really hate ALSA.

Decided today to try to test some parameters; I had left the audio card loaded with VFIO module since the command dump.

Today I've decided to retry to use it, so I've removed the VFIO stubs from modprobe, rebooted and... no PCI audio card.

Disabled IOMMU to force load the modules (something like this was already seen by me; even when VFIO wasn't asked to bind it, it would bind it anyway), no PCI audio card.

lsmod says that the module is loaded on the audio card, however no audio from any PCI devices, even the audio from the GPU.

I'll attach alsa-info.

Just for reference on your list, when the module was working, I had output working fine, but input crackling.
Comment 115 Marco 2019-07-11 07:09:20 UTC
Created attachment 283619 [details]
alsa-info now completely ignores my PCI audio cards
Comment 116 Marco 2019-07-11 07:58:54 UTC
Tried everything, including downgrade to a previous kernel, same behavior. The only thing I get in dmesg now is:

[    3.146686] hdaudio hdaudioC0D0: Unable to bind the codec
[    3.150739] hdaudio hdaudioC1D0: Unable to bind the codec

Really useful.
Comment 117 Marco 2019-07-11 10:55:11 UTC
After purging VFIO finally the PCI audio cards works again even after reenabling it. However now from the front panel only the right channel works from the front jack, from the back both works correctly.

I don't really understand anything now; nor what the problem is. I'll try to replay some interesting commands from the decoded win dump, hoping for the best; however with all this random problems popping up, I'll really doubt that I will be able to fix anything.
Comment 118 Manuel Burgstaller 2019-07-11 11:11:51 UTC
Same Bug on Manjaro with kernel 5.2 and the MSI X370 Titanium / ALC1220
Comment 119 David 2019-07-11 11:29:46 UTC
I have the same problem, input crackling, output ok.
My setup: ASUS PRIME X470-PRO (ALC1220, latest bios 5007), Ryzen 2700X, 32GB ECC RAM, Kernel 4.19.58.
This is really annoying, I'm using a USB dongle for mic input as workaround, but the SNR is not as good as the onboard audio.
Tried to fiddle with ALSA kernel module param and pulse audio param, without success.
Comment 120 João 2019-07-11 12:08:36 UTC
Same here.
Running on Asus Rog Strix b350-f Gaming.
OS: Ubuntu 19.04 - Kernel 5.0.20 - Gnome 3.32
Noticed that when I use Xorg, my input from webcam works out of the box on discord. Now on wayland I need to set tsched=0.
Looking at the syslog says that discord was trying to use 48kHz instead of the default 44.1kHz.
Already tryied to set "alternative frequency" to 44.1kHz like the default frequency, without success.
Now using a usb audio to workaround.
Comment 121 João O. 2019-07-11 20:56:57 UTC
Created attachment 283631 [details]
alsa-info on MSI X370 Krait Gaming (MS-7A33)

Adding alsa-info, same problem as everyone else - playback is perfect, mic recording crackles. 

This seems like a rather popular chipset, are we all gonna have to buy USB dongles?!
Comment 122 Alex 2019-07-12 13:37:01 UTC
Created attachment 283647 [details]
alsa-info on MSI B450 TOMAHAWK (with Realtek ALC892)

I also had the same problem with the MSI B450 Tomahawk and Ryzen 2600, I managed some time ago to make the audio output sound acceptable but the mic in default config makes a lot of noise, and after configuring pulse there's still a static noise constantly running, I had to resort to buying a cheap USB Audio Card. I also reported some time ago that I had audio issues on another thread relative to the ALC892.
Comment 123 cpw 2019-07-14 00:17:44 UTC
Just adding to the list of people noting that the ALC1220 has problems as well. I have an MSI MPG X570 Gaming Edge Wifi board, with the newest X570 chipset. The audio is unusable because of this bug - a very noticeable crackle on the input side. Output is OK. The volume of the microphone input is insanely loud - it seems to be WAY to highly amplified.

Ah well, the old soundblaster will live on into the new machine I guess.
Comment 124 jetsen 2019-07-21 05:39:56 UTC
Manjaro 18.04 with kernel 4.19, Asrock B350 Gaming ITX/ac, Ryzen 1600, Realtek ALC1220.

Both input and output are with crackling. After some tweaks in pulse daemon (changing in sample rate) input cracks are gone, but in output its still here. Also this fixes are heavy on CPU, resulting in stutters in mediacontent and gaming.
Comment 125 Takashi Iwai 2019-07-23 12:39:30 UTC
Well, it's still not clear who to blame.  Practically seen, the problem appears on a certain Realtek codecs just because there are such codec chips on the market for major mobos.  Except for a few vendors (like Apple), all boards are equipped with Realtek codecs.  So, I still suspect the problem being in HD-audio controller -- the AMD chipset side.

Can people check whether any of workarounds have any effect?  For example,

- Make sure the existing quirks for ATI boards:
  Check the PCI device ID of your HD-audio controller connected to the onboard analog audio.  You may have multiple HD-audio controller entries, and one of them is for HDMI and another for the onboard audio.
  The table in sound/pci/hda/hda_intel.c indicates the type and the quirk.  The AMD one should be with AZX_DCAPS_PRESET_ATI_SB.

- Disable the page caching.
  This can be done by passing snoop=0 option.  But maybe it's more interesting to forcibly disable the cache while keeping the PCI snoop enabled, e.g. apply a patch like:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1681,6 +1681,7 @@ static int azx_create(struct snd_card *card, struct pci_dev *pci,
 		chip->single_cmd = single_cmd;
 
 	azx_check_snoop_available(chip);
+	chip->uc_buffer = true; // XXX
 
 	if (bdl_pos_adj[dev] < 0)


- Adjust more quirk bits:
  AZX_DCAPS_PRESET_ATI_SB contains AZX_DCAPS_NO_TCSL.  Try to remove this flag, for example.
  Also, add more flags, e.g. AZX_DCAPS_NO_MSI, AZX_DCAPS_NO_MSI64, AZX_DCAPS_NO_64BIT, AZX_DCAPS_4K-BDLE_BOUNDARY.

- Try different sample rates, format, period and buffer sizes:
  At best test with aplay / arecord with -Dhw option to skip pulseaudio.
  (You can run it over pasuspender.)
  Check various parameters, e.g. 44.1k vs 48kHz, S16_LE vs S32_LE.  Try to align the period size and the buffer size to be 4kB.
Comment 126 Ernst Sjöstrand 2019-07-23 14:46:04 UTC
Thanks for the pointer Tiwai!

The problem on my board at least seems to be AZX_DCAPS_POSFIX_LPIB, which seems to get enabled by default. Some of the HDMI entries further down?

My chip is called 1022:1457 so I did something like this:
/* AMD X370 */
{ PCI_DEVICE(0x1022, 0x1457),
	  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_SNOOP_TYPE(ATI) },

Not sure what to call the entry.
I didn't notice any change with SYNC_WRITE on or off really.

Here's a way to list the pciid of you sound chip btw:
lspci | grep "HD Audio" | cut -d " " -f 1  | xargs sudo lspci -n -s
Comment 127 Takashi Iwai 2019-07-23 14:57:55 UTC
Hm, interesting, AZX_DCAPS_POSFIX_LPIB basically sets the position reporting based on LPIB instead of the position buffer.  I thought the position buffer isn't available or unreliable on non-Intel chips, but it might be different on the recent AMD one.

FWIW, you can change the behavior via position_fix option, too.  This is an array for multiple instances, so be careful if you have multiple HD-audio devices (likely on AMD).  If you pass a non-default value (e.g. 2, which means to forcibly use the position buffer) to the second card, pass like
  position_fix=,2

note the comma before "2".

AZX_DCAPS_SYNC_WRITE should be likely OK.  It essentially enables the sync after each write for the codec communication stability, i.e. it assures each command verb is executed and waiting for the response of that command.  We're going to enable this flag even for Intel chipsets, too.
Comment 128 Benjamin Cheng 2019-07-25 05:40:51 UTC
(In reply to Takashi Iwai from comment #127)
> Hm, interesting, AZX_DCAPS_POSFIX_LPIB basically sets the position reporting
> based on LPIB instead of the position buffer.  I thought the position buffer
> isn't available or unreliable on non-Intel chips, but it might be different
> on the recent AMD one.

Contrary to what Ernst experienced, removing AZX_DCAPS_POSFIX_LPIB completely broke audio on my system (ASUS PRIME X470, also 1022:1457), so I guess it's still unreliable as you mentioned.

Was looking through the pci_ids array in sound/pci/hda/hda_intel.c and noticed that my audio controller (1022:1457) isn't listed.

The only thing I can see that would match is the following, which seems to be intended for AMD GPUs.


	{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_ANY_ID),
	  .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8,
	  .class_mask = 0xffffff,
	  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI },
Comment 129 Takashi Iwai 2019-07-25 06:14:03 UTC
That's bad that the chipset shows inconsistent behavior.  How did you test exactly and how it's broken without AZX_DCAPS_POSFIX_LPIB?

As mentioned in comment 125, the first thing to do is to assure your PCI device listed in the azx_ids[] table explicitly.  If not, create an entry to pass like:
  .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB
This should be defined before the generic catch-all entry mentioned in comment 128.

I guess this entry addition won't suffice by itself, but this at least aligns with the older AMD chipset, and we can test by adjusting the AZX_DCAPS_PRESET_ATI_SB definition.

Then try other parameters mentioned in comment 125, or play with AZX_DCAPS_POSFIX_* or position_fix option.
Comment 130 Ernst Sjöstrand 2019-07-25 10:07:04 UTC
Created attachment 283955 [details]
1022 1457 patch

Here's exactly what I did, on a 5.2.0-rc5 base.

Note that it's just AZX_DRIVER_GENERIC and then the contents of ATI_SB without AZX_DCAPS_POSFIX_LPIB.
Comment 131 Ernst Sjöstrand 2019-07-25 10:24:30 UTC
Hmm ok I didn't test very properly, the crackle is gone but there seems to be some timing issues with playback, it doesn't sound correctly anymore. :-)
Comment 132 Takashi Iwai 2019-07-25 14:55:41 UTC
Then possibly the playback needs LPIB while the capture position buffer?
A patch like below...
Comment 133 Takashi Iwai 2019-07-25 14:56:57 UTC
Created attachment 283961 [details]
A test patch for PCI 1022:1457
Comment 134 David 2019-07-26 00:33:36 UTC
Tried the patch on kernel 4.19.60, no sound on input.
Comment 135 Marco 2019-07-26 10:03:02 UTC
(In reply to David from comment #134)
> Tried the patch on kernel 4.19.60, no sound on input.

Here it is working (5.2.2), but it's worse than before. I will try to play with parameters now.

Thanks for the base patch, Tiwai. I'll see if with some parameters above something will change.

However, right now the left channel from my front headphone jack is still not working.
Comment 136 Marco 2019-07-26 13:52:55 UTC
Tried quite a lot of different combination of quirks and older or latest bios with the provided patch, nothing helps. The noise frequency changes, but it is still unusable.
Comment 137 Ernst Sjöstrand 2019-07-26 15:10:00 UTC
(In reply to Takashi Iwai from comment #132)
> Then possibly the playback needs LPIB while the capture position buffer?
> A patch like below...

Nope, that didn't work. Playback was fine and recording was still crackling.

Is everyone affected here on 1022:1457 btw?
Comment 138 Marco 2019-07-26 15:41:35 UTC
(In reply to Ernst Sjöstrand from comment #137)
> (In reply to Takashi Iwai from comment #132)
> > Then possibly the playback needs LPIB while the capture position buffer?
> > A patch like below...
> 
> Nope, that didn't work. Playback was fine and recording was still crackling.
> 
> Is everyone affected here on 1022:1457 btw?

From me yes, but if you check the posted alsa-config, most of them are 1022:1457. Mine is the same.
Comment 139 Marco 2019-08-01 19:23:39 UTC
Any additional option that we can try to fix this issue, besides trying to contact AMD again for the chipset docs?
Comment 140 Takashi Iwai 2019-08-02 06:42:02 UTC
Please write down exactly what you've tested.  Otherwise we can't reduce the possible causes.
Comment 141 Marco 2019-08-02 10:55:34 UTC
(In reply to Takashi Iwai from comment #140)
> Please write down exactly what you've tested.  Otherwise we can't reduce the
> possible causes.

Tested the posted patch from you, same issue. Tried to enable all DCAPS flags (except SNOOP_MASK, SNOOP_ON, because I had used as a base the patch in attachment 283955 [details] that had already enabled SNOOP_TYPE(ATI); and I915_COMPONENT (since I do not have an integrated Intel iGPU)) on the codec specified inside line 20-47 in hda_controller.h, same issue persists. I don't really know where to proceed. The only change is in the noise frequency in time, it's more frequent or less, but the issue is still there.
Comment 142 Marco 2019-08-02 10:57:07 UTC
Created attachment 284085 [details]
Test patch with all DCAPS enabled for 1022:1457
Comment 143 Takashi Iwai 2019-08-02 13:06:39 UTC
The crucial point isn't about the DCAPS changes.  Rather other points, e.g. setting the non-cache mode *in addition* to the DCAPS changes, trying with different formats, rates, period/buffer sizes on the modified setup, etc.
And all these combos.

Basically, adding putting DCAPS* flags don't make sense because some of them are mutual exclusive.  Rather what I asked is to test to enable each DCAPS_* one by one.  But this test doesn't look so promising, so it'd be needed only to make sure for now.

Also, position_fix and bdl_pos_adj are another interesting parameters.  The test patch recently provided was based on the information about the position_fix matters...

Above all, the primary tests must be done via aplay/arecord with -Dhw option, not with PulseAudio.

***

What we need to know at this point is whether the problem happens at transferring the data itself, the update timing problem, or some problem in the codec side.

The common problems in the past are mostly the first two items: the first one is usually influenced by the memory cache coherency, and the second one is the LPIB reporting / position buffer instability or the FIFO size management.  Both might be mixed together, too.

I mentioned to test with aplay/arecord because PA is very sensible especially about the second (timing) problem.  If aplay/arecord -Dhw with a large buffer and period works, it implies that the data transfer itself is fine, for example.

So, we still need to gather the facts.  For that, the precise information about *what* you tested is important.  "I tested all" doesn't give you any clue, after all ;)
Comment 144 Marco 2019-08-02 14:14:17 UTC
(In reply to Takashi Iwai from comment #143)
> The crucial point isn't about the DCAPS changes.  Rather other points, e.g.
> setting the non-cache mode *in addition* to the DCAPS changes, trying with
> different formats, rates, period/buffer sizes on the modified setup, etc.
> And all these combos.
> 
> Basically, adding putting DCAPS* flags don't make sense because some of them
> are mutual exclusive.  Rather what I asked is to test to enable each DCAPS_*
> one by one.  But this test doesn't look so promising, so it'd be needed only
> to make sure for now.
> 
> Also, position_fix and bdl_pos_adj are another interesting parameters.  The
> test patch recently provided was based on the information about the
> position_fix matters...
> 
> Above all, the primary tests must be done via aplay/arecord with -Dhw
> option, not with PulseAudio.
> 
> ***
> 
> What we need to know at this point is whether the problem happens at
> transferring the data itself, the update timing problem, or some problem in
> the codec side.
> 
> The common problems in the past are mostly the first two items: the first
> one is usually influenced by the memory cache coherency, and the second one
> is the LPIB reporting / position buffer instability or the FIFO size
> management.  Both might be mixed together, too.
> 
> I mentioned to test with aplay/arecord because PA is very sensible
> especially about the second (timing) problem.  If aplay/arecord -Dhw with a
> large buffer and period works, it implies that the data transfer itself is
> fine, for example.
> 
> So, we still need to gather the facts.  For that, the precise information
> about *what* you tested is important.  "I tested all" doesn't give you any
> clue, after all ;)

Found a combination of parameters that seems to fix the issue with arecord, at least for 30 seconds, regardless of the sample rate (eg. 44100, 48000 or 192000, all now are clear recordings) is:
pasuspender -- arecord -D hw:1,0 -f S32_LE -r44100 -d 10 -N -c 2 /tmp/test.wav

The key parameters required are S32_LE as a format and the non blocking mode -N, otherwise the issue is still present.

I hope that this will help to track down the issue. If other people here want to try it out to see if this fix their audio problems, that would be useful as well.
Comment 145 Takashi Iwai 2019-08-02 14:32:16 UTC
Hm, that's werid.  Basically non-blocking mode matters only at opening the PCM device (whether the stream is busy or not), and it shouldn't influence on the running stream.  Maybe it's a timing issue, like other tests failed sometimes...

Did you already try using non-cached buffer in addition to the ATI-SB snooping?
Try the change like the below:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1986,7 +1986,7 @@ static int dma_alloc_pages(struct hdac_bus *bus,
 {
 	struct azx *chip = bus_to_azx(bus);
 
-	if (!azx_snoop(chip) && type == SNDRV_DMA_TYPE_DEV)
+	if (/*!azx_snoop(chip) &&*/ type == SNDRV_DMA_TYPE_DEV)
 		type = SNDRV_DMA_TYPE_DEV_UC;
 	return snd_dma_alloc_pages(type, bus->dev, size, buf);
 }
@@ -2002,7 +2002,7 @@ static void pcm_mmap_prepare(struct snd_pcm_substream *substream,
 #ifdef CONFIG_X86
 	struct azx_pcm *apcm = snd_pcm_substream_chip(substream);
 	struct azx *chip = apcm->chip;
-	if (chip->uc_buffer)
+	if (1 /*chip->uc_buffer*/)
 		area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
 #endif
 }
Comment 146 Marco 2019-08-02 14:55:08 UTC
(In reply to Takashi Iwai from comment #145)
> Hm, that's werid.  Basically non-blocking mode matters only at opening the
> PCM device (whether the stream is busy or not), and it shouldn't influence
> on the running stream.  Maybe it's a timing issue, like other tests failed
> sometimes...
> 
> Did you already try using non-cached buffer in addition to the ATI-SB
> snooping?
> Try the change like the below:
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1986,7 +1986,7 @@ static int dma_alloc_pages(struct hdac_bus *bus,
>  {
>       struct azx *chip = bus_to_azx(bus);
>  
> -     if (!azx_snoop(chip) && type == SNDRV_DMA_TYPE_DEV)
> +     if (/*!azx_snoop(chip) &&*/ type == SNDRV_DMA_TYPE_DEV)
>               type = SNDRV_DMA_TYPE_DEV_UC;
>       return snd_dma_alloc_pages(type, bus->dev, size, buf);
>  }
> @@ -2002,7 +2002,7 @@ static void pcm_mmap_prepare(struct snd_pcm_substream
> *substream,
>  #ifdef CONFIG_X86
>       struct azx_pcm *apcm = snd_pcm_substream_chip(substream);
>       struct azx *chip = apcm->chip;
> -     if (chip->uc_buffer)
> +     if (1 /*chip->uc_buffer*/)
>               area->vm_page_prot = pgprot_writecombine(area->vm_page_prot);
>  #endif
>  }

Yes, the issue is still present. I've applied attachment 283955 [details] and your last patch together.
Comment 147 Marco 2019-08-02 14:56:03 UTC
Without -N. With it the acquisition is perfect again.
Comment 148 Takashi Iwai 2019-08-02 15:19:39 UTC
OK, thanks, then this might indicate that the culprit is about the subtle timing issue, not about the cache problem.

Just to be sure, could you try to pass bdl_pos_adj=64,64 option to snd-hda-intel module?
Comment 149 Takashi Iwai 2019-08-02 15:34:05 UTC
Also, did anyone try different position_fix options, e.g. 5,5 or 4,4?
4,4 should be equivalent with my previous test patch, so it's not expected to work.

But it's still interesting to know whether the recording with such an option proceeds at all.  If the stream can be recorded for the expected length, no matter whether it's noisy or not, it means that the position buffer does work in some level.  OTOH, if the stream can't be recorded at all (e.g. you get the DMA or stall error), the position buffer is broken on AMD platform.
Comment 150 Marco 2019-08-02 15:35:12 UTC
(In reply to Takashi Iwai from comment #148)
> OK, thanks, then this might indicate that the culprit is about the subtle
> timing issue, not about the cache problem.
> 
> Just to be sure, could you try to pass bdl_pos_adj=64,64 option to
> snd-hda-intel module?

I feel dumb, I had some options inside modprobe that was fixing the issue with -N apparently. After wiping it out and setting the above parameter to 64,64, the issue is present regardless of the -N parameter. I'll try to change it until I'll get the same behavior as before, or play again with parameters until I can fix it properly?
Comment 151 Takashi Iwai 2019-08-02 15:37:53 UTC
No need for retest, bdl_pos_adj is merely a shot-in-the-dark, and likely breaks something else :)
Comment 152 Marco 2019-08-02 15:57:43 UTC
(In reply to Takashi Iwai from comment #149)
> Also, did anyone try different position_fix options, e.g. 5,5 or 4,4?
> 4,4 should be equivalent with my previous test patch, so it's not expected
> to work.
> 
> But it's still interesting to know whether the recording with such an option
> proceeds at all.  If the stream can be recorded for the expected length, no
> matter whether it's noisy or not, it means that the position buffer does
> work in some level.  OTOH, if the stream can't be recorded at all (e.g. you
> get the DMA or stall error), the position buffer is broken on AMD platform.

I can't believe it, it works now with position_fix = 3! I don't know if this was caused by the additional patch to the kernel, I'll probably try to remove it to see if it is still working with 3, but I had already tried all position fix and a heap of other stuff.

The audio now is perfect, even with pulseaudio :)

This is the result that you have requested anyway:

0: Same problem, no other issues
1: Same problem, no other issues
2: Unable to acquire stream, arecord signal overrun!!! (at least 377,780 ms long) and no audio is acquired
3: No clicking in the acquired stream!
4: Same problem, no other issues
Comment 153 Takashi Iwai 2019-08-02 16:05:17 UTC
It's a good news.  3 is a workaround for VIA chip, but this seems applicable to AMD, then.

The only concern is whether the AMD chip really provides the right FIFO size by the register read for VIA.  Could you check which value is shown by the patch below?  If it's 32 or some reasonable number, it's fine.

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1467,6 +1467,9 @@ static void assign_position_fix(struct azx *chip, int fix)
 			azx_get_delay_from_lpib;
 	}
 
+	pr_info("XXX fifo_size = %d\n",
+		readw(azx_bus(chip)->remap_addr +
+		      VIA_IN_STREAM0_FIFO_SIZE_OFFSET));
 }
Comment 154 Marco 2019-08-02 16:34:30 UTC
(In reply to Takashi Iwai from comment #153)
> It's a good news.  3 is a workaround for VIA chip, but this seems applicable
> to AMD, then.
> 
> The only concern is whether the AMD chip really provides the right FIFO size
> by the register read for VIA.  Could you check which value is shown by the
> patch below?  If it's 32 or some reasonable number, it's fine.
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1467,6 +1467,9 @@ static void assign_position_fix(struct azx *chip, int
> fix)
>                       azx_get_delay_from_lpib;
>       }
>  
> +     pr_info("XXX fifo_size = %d\n",
> +             readw(azx_bus(chip)->remap_addr +
> +                   VIA_IN_STREAM0_FIFO_SIZE_OFFSET));
>  }

I have the suspect that it doesn't, since it mentions a null pointer kernel dereference; module crash attached below.
Comment 155 Marco 2019-08-02 16:35:24 UTC
Created attachment 284089 [details]
Kernel Bug reported when trying to access VIA register on a AMD platform
Comment 156 Marco 2019-08-02 16:37:48 UTC
Regardless, it works even without any patch with position_fix = 3 on the latest stable kernel, 5.2.5. I had already tried that but now it actually works.

In the hope that this will help,

Marco.
Comment 157 Marco 2019-08-02 17:14:07 UTC
Latest addition, tsched=0 is still required to have decent audio acquisition, otherwise the audio is stretched in time. A lot. Otherwise, after setting that, the audio is perfect now.
Comment 158 Takashi Iwai 2019-08-02 17:14:55 UTC
My bad, it was a wrong place to peek the value.

Below is a revised one.  Also it shows the similar information that should be available in the stream data.  This may spew many messages, so it's enough just to get a few messages at testing recording.
Comment 159 Takashi Iwai 2019-08-02 17:15:25 UTC
Created attachment 284091 [details]
A patch to show the fifo size
Comment 160 Rafael Rossi 2019-08-02 17:26:17 UTC
Just to confirm that using


`pasuspender -- arecord -D hw:1,0 -f S32_LE -r44100 -d 10 -N -c 2 /tmp/test.wav`


I did manage to get good audio without any kernel patch (4.15.0-55-generic).

I've only get left channel though. But that's same even in noisy signal.
Comment 161 Marco 2019-08-02 17:46:12 UTC
(In reply to Takashi Iwai from comment #158)
> My bad, it was a wrong place to peek the value.
> 
> Below is a revised one.  Also it shows the similar information that should
> be available in the stream data.  This may spew many messages, so it's
> enough just to get a few messages at testing recording.

This works, and yes, reported sizes makes sense.

I don't really get why an AMD/AsMedia chipset is acting as a VIA one, but it does look like that that's the case.

Output attached below.
Comment 162 Marco 2019-08-02 17:46:47 UTC
Created attachment 284093 [details]
FIFO sizes from a AMD chipset
Comment 163 Takashi Iwai 2019-08-02 18:26:53 UTC
OK, that looks more promising.

Now I cooked two patches.  The first one is to simply apply the existing VIA position fix to the AMD X370 platform (1022:1457).  This should work like the test you've done now without any option.

The second one is an attempt with simpler position fix, just reducing the fifo size.  Give this a try instead of the first patch.

There are adjustable knobs in the second patch, at azx_get_pos_amd() function; the first one is whether to apply the correction to the playback stream, too.  Since there was a report about the playback stuttering, I enabled it here, but you can try to change it.  The second knob is the fifo_size retrieval, whether to read from the same register as VIA, or from the SD stream register.  The end result might be same, but we need experiments.
Comment 164 Takashi Iwai 2019-08-02 18:28:05 UTC
Created attachment 284097 [details]
Test fix patch no.1
Comment 165 Takashi Iwai 2019-08-02 18:28:36 UTC
Created attachment 284099 [details]
Test fix patch no.2
Comment 166 David 2019-08-03 00:00:16 UTC
Wow! This is so good. "patch no.2" is working great, no need to set tsched=0 anymore with that one.
Comment 167 David 2019-08-03 01:11:13 UTC
Tried the same patch #2 with "fifo_size = azx_dev->core.fifo_size;" instead. same good results. (tested both method on kernel 4.19.63)
Comment 168 Takashi Iwai 2019-08-03 07:07:05 UTC
OK, thanks.  Could you try another one below, too?

This should be a more correct way from API POV, passing the delay value instead of the direct correction of the position.
Comment 169 Takashi Iwai 2019-08-03 07:07:35 UTC
Created attachment 284111 [details]
Test fix patch no.3
Comment 170 Takashi Iwai 2019-08-03 07:43:20 UTC
Created attachment 284113 [details]
Test fix patch (revised)

The previous one won't work, I'm afraid.  This is the revised one (no.4).
Comment 171 Marco 2019-08-03 08:18:50 UTC
I confirm that both version of the second patch work. On playback I had only some minor issues when the stream was starting, but after enabling the playback patch, they disappeared too.

Without tsched=0 and without the playback patch, acquisition work perfectly fine, but not the output, is delayed in time again.

Forgot to test it without tsched and playback and data from fifo directly and not from VIA register, but I can recompile it if it is needed.

I think that both patches are needed, even if my playback issue wasn't that problematic.

Testing n.4 shortly.

Thanks a ton for your work.
Comment 172 Takashi Iwai 2019-08-03 08:34:27 UTC
Thanks.  The problem with playback indicates that the delay correction isn't good for playback but only for capture.

Below is yet another revised patch.  It corrects the position report only for the capture, but takes the FIFO delay into account, too.
Comment 173 Takashi Iwai 2019-08-03 08:34:57 UTC
Created attachment 284117 [details]
Test fis patch no.5
Comment 174 Takashi Iwai 2019-08-03 08:41:10 UTC
BTW, does anyone hit the problem on an AMD board with other PCI ID than 1022:1457?
Comment 175 Marco 2019-08-03 09:00:54 UTC
(In reply to Takashi Iwai from comment #172)
> Thanks.  The problem with playback indicates that the delay correction isn't
> good for playback but only for capture.
> 
> Below is yet another revised patch.  It corrects the position report only
> for the capture, but takes the FIFO delay into account, too.

Number 4 works perfectly with tsched=0, but not without, stutters again (delayed and crackled, probably from playback this time since you mentioned it). I'll test patch v5 and report back.
Comment 176 Marco 2019-08-03 09:04:55 UTC
(In reply to Takashi Iwai from comment #174)
> BTW, does anyone hit the problem on an AMD board with other PCI ID than
> 1022:1457?

Another thing, 1022:1457 is not used only on X370, but also on my B450, and probably on a lot of other board, like B350 and such. Just a remark for the comment mentioning only X370 over the PCI device :)

Thanks again,

Marco.
Comment 177 daxcore 2019-08-03 09:06:14 UTC
(In reply to Marco from comment #176)
> (In reply to Takashi Iwai from comment #174)
> > BTW, does anyone hit the problem on an AMD board with other PCI ID than
> > 1022:1457?
> 
> Another thing, 1022:1457 is not used only on X370, but also on my B450, and
> probably on a lot of other board, like B350 and such. Just a remark for the
> comment mentioning only X370 over the PCI device :)
> 
> Thanks again,
> 
> Marco.

ID 1022:1457 also used for AMD X399.
Comment 178 Luca Osvaldo M. 2019-08-03 09:28:20 UTC
1022:1457 also on my MSI AMD B350M, on ALC892 codec
Comment 179 Ivan 2019-08-03 09:44:05 UTC
Gigabyte X470 AORUS ULTRA
ALC1220, [1022:1457] subsys [1458:a0c3] 

Test Fis Patch no.5 on kernel 5.1.5:
- sound playback OK
- sound recording OK ( crackling disappeared )
Comment 180 Marco 2019-08-03 09:48:33 UTC
(In reply to Takashi Iwai from comment #172)
> Thanks.  The problem with playback indicates that the delay correction isn't
> good for playback but only for capture.
> 
> Below is yet another revised patch.  It corrects the position report only
> for the capture, but takes the FIFO delay into account, too.

With tsched=0, everything is perfect. When tsched=0 is removed, the audio output is not crackling again, however ALL audio is retarded when the acquisition starts, to me it feels around 4/5 seconds. I had a player playing music in background and the whole stream jump back for that time; if i try to seek in another position the audio will seek only after the same 4/5 seconds. If I stop capturing audio, the playback sync back again and the playback is working correctly again.

Very weird.
Comment 181 Luca Osvaldo M. 2019-08-03 10:27:46 UTC
(In reply to Takashi Iwai from comment #173)
> Created attachment 284117 [details]
> Test fis patch no.5

Tested on 1022:1457 also on my MSI AMD B350M, on ALC892 codec, Kernel 5.2.5

Works fine, thanks.

I'll try to build an ubuntu package with this kernel patch for 5.0
Comment 182 alpir 2019-08-03 10:32:01 UTC
ASRock Fatal1ty B450 Gaming K4
ALC892, [1022:1457] subsys [1849:9893] 

Test Fis Patch no.5 with kernel 4.19.57:
- sound playback OK
- sound recording OK (no crackling)
Comment 183 Luca Osvaldo M. 2019-08-03 10:32:40 UTC
(In reply to Luca from comment #181)
> (In reply to Takashi Iwai from comment #173)
> > Created attachment 284117 [details]
> > Test fis patch no.5
> 
> Tested on 1022:1457 also on my MSI AMD B350M, on ALC892 codec, Kernel 5.2.5
> 
> Works fine, thanks.
> 
> I'll try to build an ubuntu package with this kernel patch for 5.0

Oh sorry I spoke too soon! 

However, sound capture definitely works fine when tested on https://webcammictest.com/check-microphone.html (it didn't before this patch)

However, the sound still crackles on both input/output when using Discord.
Comment 184 Takashi Iwai 2019-08-03 11:52:55 UTC
Then can anyone test the hack in comment 145 together with patch#5?
Comment 185 Marco 2019-08-03 12:42:04 UTC
(In reply to Takashi Iwai from comment #184)
> Then can anyone test the hack in comment 145 together with patch#5?

Same behavior as without, with tsched is perfect, without the stream jump back in time here, but the audio is clean, as mentioned in comment 180.
Comment 186 David 2019-08-03 13:23:48 UTC
I don't see any difference between patch 2a 2b 4 or 5. Capture or playback, tsched=0 or tsched=1.

My chipset is X470, [1022:1457], ALC1220.
Comment 187 daxcore 2019-08-03 14:00:24 UTC
also not working for me with kernel 5.3rc2 (archlinux: linux-git) and patch no. 5. ALC1220 X399 MSI board [1022:1457].
Comment 188 Takashi Iwai 2019-08-03 16:02:03 UTC
For those with non-working systems: first off, make sure that you're really testing the patched kernel, e.g. put a printk() for checking.

Then test without PulseAudio at first, with aplay/arecord (with -Dhw:0 or -Dhw:1, depending on the system).  As in comment 144, try with or without -N.
Comment 189 Takashi Iwai 2019-08-03 16:13:57 UTC
(In reply to Marco from comment #180)
> (In reply to Takashi Iwai from comment #172)
> > Thanks.  The problem with playback indicates that the delay correction
> isn't
> > good for playback but only for capture.
> > 
> > Below is yet another revised patch.  It corrects the position report only
> > for the capture, but takes the FIFO delay into account, too.
> 
> With tsched=0, everything is perfect. When tsched=0 is removed, the audio
> output is not crackling again, however ALL audio is retarded when the
> acquisition starts, to me it feels around 4/5 seconds. I had a player
> playing music in background and the whole stream jump back for that time; if
> i try to seek in another position the audio will seek only after the same
> 4/5 seconds. If I stop capturing audio, the playback sync back again and the
> playback is working correctly again.
> 
> Very weird.

So something goes wrong in the full-duplex operation?  That is, if you do only capture or only playback, it works even without tsched workaround?

Another shot-in-the-dark is to swap the stream assignment, something like:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1853,8 +1853,8 @@ static int azx_first_init(struct azx *chip)
 			break;
 		}
 	}
-	chip->capture_index_offset = 0;
-	chip->playback_index_offset = chip->capture_streams;
+	chip->playback_index_offset = 0;
+	chip->capture_index_offset = chip->playback_index_offset;
 	chip->num_streams = chip->playback_streams + chip->capture_streams;
 
 	/* sanity check for the SDxCTL.STRM field overflow */

It's unlikely that this has any effect, but who knows...

Another quirk regarding the stream assignment is AZX_DCAPS_SEPARATE_STREAM_TAG flag, which is used for the recent Intel chips.  Check whether it gives any positive changes.
Comment 190 Marco 2019-08-03 17:16:56 UTC
(In reply to Takashi Iwai from comment #189)
> (In reply to Marco from comment #180)
> > (In reply to Takashi Iwai from comment #172)
> > > Thanks.  The problem with playback indicates that the delay correction
> > isn't
> > > good for playback but only for capture.
> > > 
> > > Below is yet another revised patch.  It corrects the position report only
> > > for the capture, but takes the FIFO delay into account, too.
> > 
> > With tsched=0, everything is perfect. When tsched=0 is removed, the audio
> > output is not crackling again, however ALL audio is retarded when the
> > acquisition starts, to me it feels around 4/5 seconds. I had a player
> > playing music in background and the whole stream jump back for that time;
> if
> > i try to seek in another position the audio will seek only after the same
> > 4/5 seconds. If I stop capturing audio, the playback sync back again and
> the
> > playback is working correctly again.
> > 
> > Very weird.
> 
> So something goes wrong in the full-duplex operation?  That is, if you do
> only capture or only playback, it works even without tsched workaround?
> 
> Another shot-in-the-dark is to swap the stream assignment, something like:
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -1853,8 +1853,8 @@ static int azx_first_init(struct azx *chip)
>                       break;
>               }
>       }
> -     chip->capture_index_offset = 0;
> -     chip->playback_index_offset = chip->capture_streams;
> +     chip->playback_index_offset = 0;
> +     chip->capture_index_offset = chip->playback_index_offset;
>       chip->num_streams = chip->playback_streams + chip->capture_streams;
>  
>       /* sanity check for the SDxCTL.STRM field overflow */
> 
> It's unlikely that this has any effect, but who knows...
> 
> Another quirk regarding the stream assignment is
> AZX_DCAPS_SEPARATE_STREAM_TAG flag, which is used for the recent Intel
> chips.  Check whether it gives any positive changes.

Sorry, just noticed now, the input is not delayed, the signal on the screen is in sync with my voice, it's only the output that is retarded by 4 seconds.

Trying now the DCAPS and then the patch supplied.

Thanks again,

Marco.
Comment 191 Térence Clastres 2019-08-03 17:18:52 UTC
If you are on ArchLinux, I made a dkms package: https://aur.archlinux.org/packages/snd_hda_intel-alc1220-dkms/ which for now applies "Test fix patch no.2" as I found like others it was working well.
I will certainly update it based on the reporters feedback from the different patches to try.

Thanks a lot for your work Takashi Iwai!
Comment 192 Marco 2019-08-03 18:01:17 UTC
Neither did nothing, however the audio playback has no problem staying in sync if I use directly arecord, even without pausing pulseaudio.

So, it is a pulseaudio bug, if with arecord everything works correctly?

Thanks a lot again,

Marco.
Comment 193 Takashi Iwai 2019-08-03 19:29:04 UTC
It's hard to say whether it's a PA bug.  I still doubt it being some inconsistent behavior of the driver, triggered only by some specific condition PA hits.

Could you start PA with more verbosity and check whether PA complains anything at starting capture?  It might be that the incorrect position screws up PA, or something like that.
Comment 194 David 2019-08-03 19:50:06 UTC
Marco, I would like to try your issue on my side, can you share the step to reproduce the problem, maybe your default.pa file too.
Comment 195 Marco 2019-08-03 20:13:15 UTC
Here is the pulseaudio log and the default.pa from my system, but the config (beside realtime scheduling) are unchanged:
Comment 196 Marco 2019-08-03 20:13:56 UTC
Created attachment 284137 [details]
pulseaudio log without tsched=0 when acquiring audio
Comment 197 Marco 2019-08-03 20:14:50 UTC
Created attachment 284139 [details]
My default.pa config file from pulseaudio
Comment 198 Marco 2019-08-03 20:17:34 UTC
The only step is to not use tsched and try to use a software that use webrtc as a audio backend, like Discord.

As soon as you test your mic, the audio in playback get shifted back in time, around 5 seconds.

Thanks both for your time,

Marco.
Comment 199 David 2019-08-03 23:33:40 UTC
Marco, I see your issue with discord, there is a delay in the output when tsched=1.

Sometime the sound get 'robotic', or there is a pre-echo and an echo, sometime the issue vanish when I play around with other application that capture or playback audio.

This remind me a weird audio issue I had with my previous system (old core 2) in some steam game in the past, not sure if it's a kernel issue.

[tested with patch #4 and #5 on kernel 4.19.63]
Comment 200 Takashi Iwai 2019-08-04 06:31:53 UTC
A possible explanation about the delay at playback while capturing is that the FIFO size reported for each stream is influenced by other action.  The patch assumed that it's constant (like other platforms do), but AMD might vary it per state.

The patch below (fix6) takes a hard-coded FIFO size.  Check it out.

There is one adjustment knob in the patch for an open question; whether the fixed FIFO size is in frames (samples) or in bytes, i.e. if the sample format changes from 32 to 16bit, whether FIFO size changes, too.
If the patch was confirmed to work more or less, try to define/undefine AMD_FIXED_FIFO_IN_FRAMES, and check the behavior with S16 or S32 formats (on PA setup and/or aplay/arecord parameters).
Comment 201 Takashi Iwai 2019-08-04 06:32:35 UTC
Created attachment 284155 [details]
Test fix patch no.6
Comment 202 Takashi Iwai 2019-08-04 06:35:57 UTC
Created attachment 284157 [details]
The correct no.6 test patch

Oops, sorry the previous no.6 was wrong.  The correct one here.
Comment 203 Luca Osvaldo M. 2019-08-04 08:56:25 UTC
(In reply to Takashi Iwai from comment #202)
> Created attachment 284157 [details]
> The correct no.6 test patch
> 
> Oops, sorry the previous no.6 was wrong.  The correct one here.

Hi, I tested this patch and it seems to be working fine. 

1) Test made at https://webcammictest.com/check-microphone.html, it works fine as the previous patch. This is a self hear test, everything works perfectly

2) Second test was made opening discord and using the builtin mic test, which also has a builtin self hear test.

But, this time the output sound crackled for the first 3/4 seconds, then it was working fine. Unlike the previous patch where it was still present after that amount of time

Kernel 5.2.5.
Comment 204 Luca Osvaldo M. 2019-08-04 09:51:30 UTC
Hmm... I am noticing something strange between old and new kernels.

Without any patch applied, on the kernel 5.2.5 as Marco said, is working fine after a couple of seconds (with or without position-fix=3) BUT a little bit of sound distortion is present without the Iwai patch 6.

On older kernels than 5.2.5 like 4.19.63 the output issue "disappears" with Iwai's patch after a minute, so it takes longer.

I think the issue is on the playback, because when I open Discord even the system audio crackles. But still I'm not sure.

Is it possible newer kernels already have a partial workaround? I also noticed the patch modifies less lines on 5.2.5.
Comment 205 Luca Osvaldo M. 2019-08-04 10:38:27 UTC
Another update, on kernel 4.19.63 with position_fix=3 the output crackling lasts 10 seconds. So to me it looks like that parameter is somehow "applied" to the 5.2.5 kernel by default??
Comment 206 Marco 2019-08-04 10:45:10 UTC
(In reply to Takashi Iwai from comment #200)
> A possible explanation about the delay at playback while capturing is that
> the FIFO size reported for each stream is influenced by other action.  The
> patch assumed that it's constant (like other platforms do), but AMD might
> vary it per state.
> 
> The patch below (fix6) takes a hard-coded FIFO size.  Check it out.
> 
> There is one adjustment knob in the patch for an open question; whether the
> fixed FIFO size is in frames (samples) or in bytes, i.e. if the sample
> format changes from 32 to 16bit, whether FIFO size changes, too.
> If the patch was confirmed to work more or less, try to define/undefine
> AMD_FIXED_FIFO_IN_FRAMES, and check the behavior with S16 or S32 formats (on
> PA setup and/or aplay/arecord parameters).

Forgot to test with aplay without PA with the define disabled, however the acquired audio with PulseAudio was bad, like "low quality" (and the output was delayed as before). Using arecord (but not with PA disabled) I was hearing again a little of crackling. With the define the audio was perfect again with arecord (however only with PA disabled, I've tried to use aplay in another terminal while using arecord, however the audio is played back only when PA resumes; I'm not sure if this is something to be expected), same thing with PA; however the output was delayed again (when acquiring from PA). I've tested both S16 and S32 with the define and pulseaudio disabled, no problem heard.
Comment 207 Takashi Iwai 2019-08-04 15:36:12 UTC
Did you try to define AMD_FIXED_FIFO_IN_FRAMES in the patch, too?
Also, try to increase the FIFO size defined there.  The current value (256 bytes and 32 frames) is just a guess work and it might need larger size.

And, the delay happens even with the patch no.6?  Then my theory wasn't right, and it implies that the position reporting itself is delayed or the transfer is delayed by some reason.

For analyzing it, we'd need the even tracing.  Please try to get trace logs in /sys/kernel/debug/tracing/events/hda_controller while capturing and the retard playback.  Some instructions are found in Documentation/sound/hd-audio/notes.rst.
Comment 208 henk717 2019-08-04 17:07:01 UTC
Did some tests using the AUR package snd_hda_intel-alc1220-dkms (Seems to be Patch 2) on the 1022:1457 ALC1220 (X370 Pro Carbon motherboard).
Using the default settings i no longer hear the robotic echo issues in my microphone recordings and i am able to get good recordings with Audacity. tsched=0 seems to have feint audio issues which are similar to my best case scenario without the patch. It is hard to hear and could be a tsched=0 only issue.

However more worryingly i was able to reproduce my former Audacity "Dolphin speed" issue where it records way faster than it should. While not present by default this happens after i use pulseaudio -k and then try to use Audacity. This does not happen on my laptop with an Intel Motherboard and connexant audio chip indicating it is still driver related. The effect happens both on the "pulse" microphone and on the direct microphone when selected.

Perhaps this is already resolved in the future patches, but i found this an easy to replicate testing scenario to see if underlying bugs are present.
Comment 209 Marco 2019-08-04 18:13:48 UTC
(In reply to Takashi Iwai from comment #207)
> Did you try to define AMD_FIXED_FIFO_IN_FRAMES in the patch, too?
> Also, try to increase the FIFO size defined there.  The current value (256
> bytes and 32 frames) is just a guess work and it might need larger size.
> 
> And, the delay happens even with the patch no.6?  Then my theory wasn't
> right, and it implies that the position reporting itself is delayed or the
> transfer is delayed by some reason.
> 
> For analyzing it, we'd need the even tracing.  Please try to get trace logs
> in /sys/kernel/debug/tracing/events/hda_controller while capturing and the
> retard playback.  Some instructions are found in
> Documentation/sound/hd-audio/notes.rst.

Compiling a *4 in the parameters, I'll report back shortly.

Yes, the only clean audio stream from PA and arecord was with the define enabled in the source code.

If it doesen't change, i'll post a trace from the codec.
Comment 210 Marco 2019-08-04 18:28:10 UTC
Nothing changed, here is the trace and the actions:

1) Opened VLC with a song
2) Opened discord
3) Started mic testing, output jumped back 5 seconds in the past
4) Ended mic testing, output re synced back.
5) Stopped VLC playing
Comment 211 Marco 2019-08-04 18:29:54 UTC
Created attachment 284171 [details]
Codec trace for the audio output delay problem
Comment 212 Luca Osvaldo M. 2019-08-04 19:18:06 UTC
How does position_fix = 6 (the FIFO that the patch adds) work?

Because when I add it, makes the system (only for GNOME) laggy when using Discord, exacly like before as I said in comment 86 https://bugzilla.kernel.org/show_bug.cgi?id=195303#c86
But this time obviously the mic capture is fine.

Still in all those cases, the playback is distorted/robotic for a minute or so.

But I remember the voice to be robotic months ago like this only when using Arch Linux??? (So an updated kernel, instead of the Ubuntu LTS I use right now) but since I used an USB card since now, I don't remember how the playback was working previously, I'm sure the microphone capture was still bad before this patch solved it
Comment 213 henk717 2019-08-04 20:50:34 UTC
Discord being robotic can happen on functional audio cards as well, i for example had it on my laptop in the past. When subject to the real bug this does not clear up at all and will remain an issue for a while. The non related bug in discord itself i can usually get rid off by opening and closing other applications like my webbrowser and yes it does clear up on its own as well.
Comment 214 Ernst Sjöstrand 2019-08-06 07:12:30 UTC
There's a lot to track here now, but patch #2 seems to work great here!

Patch #6 didn't seem to cause any new problems for me, but the crackling is still there.
Comment 215 Marco 2019-08-06 07:20:21 UTC
(In reply to Ernst Sjöstrand from comment #214)
> There's a lot to track here now, but patch #2 seems to work great here!
> 
> Patch #6 didn't seem to cause any new problems for me, but the crackling is
> still there.

6 works only with the define enabled, remove the double slashes in front of #define, then it will work.

Still, this works only with tsched=0 (which to me is good enough, honestly), but if we can fix even the last issue, that would be perfect.
Comment 216 Takashi Iwai 2019-08-06 09:23:43 UTC
(In reply to Marco from comment #211)
> Created attachment 284171 [details]
> Codec trace for the audio output delay problem

Could you get the trace log for hda_controller, not hda? (/sys/kernel/debug/tracing/events/hda_controller)

The former tracks the PCM events including the position report while the latter tracks only CORB/RIRB communications (i.e. the verb execution).
Comment 217 Marco 2019-08-06 09:42:38 UTC
(In reply to Takashi Iwai from comment #216)
> (In reply to Marco from comment #211)
> > Created attachment 284171 [details]
> > Codec trace for the audio output delay problem
> 
> Could you get the trace log for hda_controller, not hda?
> (/sys/kernel/debug/tracing/events/hda_controller)
> 
> The former tracks the PCM events including the position report while the
> latter tracks only CORB/RIRB communications (i.e. the verb execution).

Whoops, my mistake. Here is the correct trace from hda_controller, same sequence of action taken:
Comment 218 Marco 2019-08-06 09:44:34 UTC
Created attachment 284211 [details]
hda_controller trace from the timing issue of my ALC892
Comment 219 Takashi Iwai 2019-08-06 09:55:10 UTC
Is this with tsched=0?  I wonder why PA gets the position information so often.  Without tsched change, PA should access to the hardware much less frequently.

In anyway, one another interesting experiment is to reduce the max period size, something like below on top of the previous patch:

--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -607,6 +607,7 @@ static int azx_pcm_open(struct snd_pcm_substream *substream)
 	runtime->hw.channels_max = hinfo->channels_max;
 	runtime->hw.formats = hinfo->formats;
 	runtime->hw.rates = hinfo->rates;
+	runtime->hw.period_bytes_max =	32768; // XXX
 	snd_pcm_limit_hw_rates(runtime);
 	snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
 
This is merely a hackish workaround, but worth to try.
Comment 220 Marco 2019-08-06 09:59:02 UTC
(In reply to Takashi Iwai from comment #219)
> Is this with tsched=0?  I wonder why PA gets the position information so
> often.  Without tsched change, PA should access to the hardware much less
> frequently.
> 
> In anyway, one another interesting experiment is to reduce the max period
> size, something like below on top of the previous patch:
> 
> --- a/sound/pci/hda/hda_controller.c
> +++ b/sound/pci/hda/hda_controller.c
> @@ -607,6 +607,7 @@ static int azx_pcm_open(struct snd_pcm_substream
> *substream)
>       runtime->hw.channels_max = hinfo->channels_max;
>       runtime->hw.formats = hinfo->formats;
>       runtime->hw.rates = hinfo->rates;
> +     runtime->hw.period_bytes_max =  32768; // XXX
>       snd_pcm_limit_hw_rates(runtime);
>       snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
>  
> This is merely a hackish workaround, but worth to try.

No, this is with tsched removed from the parameter, so it should be one. I’m forcing tsched to zero to not have the issue in PA, otherwise the issue is not present.

If you like, I can post the same trace with tsched=0, if that will help you narrow down the issue.

I’ll try the patch shortly,

Thanks again for your time,

Marco.
Comment 221 Takashi Iwai 2019-08-06 10:39:45 UTC
OK, thanks.  Then it looks like that it's really the chip that stalls the playback.  Around time 8102 until 8106, there is no playback position update and proceed.  The same position is kept for 4 seconds by some reason.

If this happens only at the full-duplex (capture and playback mixture) trigger time, it might be in the SYNC register operation.  In that case, a change like below might influence on the behavior.
Comment 222 Takashi Iwai 2019-08-06 10:40:51 UTC
Created attachment 284213 [details]
Patch to remove stream sync calls
Comment 223 Marco 2019-08-06 10:58:54 UTC
(In reply to Takashi Iwai from comment #221)
> OK, thanks.  Then it looks like that it's really the chip that stalls the
> playback.  Around time 8102 until 8106, there is no playback position update
> and proceed.  The same position is kept for 4 seconds by some reason.
> 
> If this happens only at the full-duplex (capture and playback mixture)
> trigger time, it might be in the SYNC register operation.  In that case, a
> change like below might influence on the behavior.

Nothing changed, unfortunately. Same behavior as before :(
Comment 224 Takashi Iwai 2019-08-06 12:00:29 UTC
OK.  And changing the period_bytes_max doesn't have any influence, either?
Comment 225 Marco 2019-08-06 13:08:13 UTC
(In reply to Takashi Iwai from comment #224)
> OK.  And changing the period_bytes_max doesn't have any influence, either?

Whoops, I completely forgot about the previous hack. Unfortunately, nothing changes; same thing, same timing.
Comment 226 Takashi Iwai 2019-08-06 13:45:46 UTC
Then I have no better idea for now than disabling the tsched on PA.

The patch below is a combination of the former patch (modified no.6) and the flag set to enforce tsched=0.  This should work without changing PA config.

Let me know if this works better.  If the things work reasonably enough, I'm going to push it to upstream.
Comment 227 Takashi Iwai 2019-08-06 13:46:19 UTC
Created attachment 284221 [details]
Test fix patch no.7
Comment 228 Marco 2019-08-06 14:33:47 UTC
(In reply to Takashi Iwai from comment #226)
> Then I have no better idea for now than disabling the tsched on PA.
> 
> The patch below is a combination of the former patch (modified no.6) and the
> flag set to enforce tsched=0.  This should work without changing PA config.
> 
> Let me know if this works better.  If the things work reasonably enough, I'm
> going to push it to upstream.

All is working fine here from my side.
Comment 229 daxcore 2019-08-06 17:58:47 UTC
completely not working here. also not patch 7. with pa sound is jumping, and with alsa I just get a random noise.

does this work for anybody with X399 board alc1220?
Comment 230 Takashi Iwai 2019-08-06 21:06:07 UTC
(In reply to daxcore from comment #229)
> completely not working here. also not patch 7. with pa sound is jumping, and
> with alsa I just get a random noise.
> 
> does this work for anybody with X399 board alc1220?

That sounds like a different problem.  Especially a random noise shouldn't be caused by the DMA position bug.  Try to clear the audio setup once.

Does the audio work on any other OS at all?
Comment 231 David 2019-08-06 21:50:34 UTC
Everything seems good so far, input not crackling, discord ok. 

ALC1220 on X470.
Comment 232 Térence Clastres 2019-08-07 04:19:55 UTC
I notice the following in the log with patch 7:
Also, I don't know if it's expected but enabling 'mic boost' produces a lot of noise.

pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail.
pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers.
pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: ALSA woke us up to read new data from the device, but there was actually nothing to read.
Comment 233 Takashi Iwai 2019-08-07 06:42:15 UTC
(In reply to Térence Clastres from comment #232)
> I notice the following in the log with patch 7:
> Also, I don't know if it's expected but enabling 'mic boost' produces a lot
> of noise.
> 
> pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: We were
> woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0
> or another value < min_avail.

That's mostly harmless chats from PA unless you hear anything obvious due to this.  The noise by the mic boost is also normal.  It's rather a codec side problem and the hardware implementation itself.
Comment 234 Ernst Sjöstrand 2019-08-07 10:20:51 UTC
Patch 7 works very well here too AFAICT. Multiple playback streams and recording  at the same time with PA.

With patch 2 you didn't have to disable tsched, but perhaps that was a horrible hack in some other way.. ?

(And I can go pretty high on mic boost without very much noise).
Comment 235 Takashi Iwai 2019-08-07 10:26:23 UTC
Basically patch 2 and 7 are essentially doing same wrt the position report.  The latter uses the fixed FIFO size instead of reading the register and it reports the actual delay size as well.  But the difference is likely irrelevant with PA tsched problem Marco was seeing.

I guess PA would work without tsched hack even after removing the BATCH flag hack from the patch7 on your machine.  I really have no idea what triggers the problem and how.  More experiment results are appreciated.

In anyway, I already submitted the patch7 to upstream and merged now.  It'll be included in the next pull request to Linus, so likely landed in 5.3-rc4, then backported to stable trees afterward.
Comment 236 Ernst Sjöstrand 2019-08-07 11:30:40 UTC
Patch 7 does not work on my system with the runtime->hw.info |= SNDRV_PCM_INFO_BATCH; statement removed.
Comment 237 Takashi Iwai 2019-08-07 11:52:40 UTC
What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1], together with dropping SNDRV_PCM_INFO_BATCH flag?  Still getting the same problem?
Comment 238 David 2019-08-07 12:20:57 UTC
Tried patch #7 without BATCH flag, this is not working with discord, there is a delay, and the playback stream jump around when pressing button "Let's Check".
Comment 239 Marco 2019-08-07 12:38:42 UTC
(In reply to David from comment #238)
> Tried patch #7 without BATCH flag, this is not working with discord, there
> is a delay, and the playback stream jump around when pressing button "Let's
> Check".

Yea, same here on B450/ALC892 with tsched enabled (which AFAIK the batch flag is the same of disabling tsched on the kernel side of things). Other chipsets instead seems to behave differently (if it is the front end and not the backend, the Realtek codec).

Very weird.
Comment 240 Ernst Sjöstrand 2019-08-07 18:12:01 UTC
(In reply to Takashi Iwai from comment #237)
> What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1],
> together with dropping SNDRV_PCM_INFO_BATCH flag?  Still getting the same
> problem?

I getting the crackling mic input if I do that yes.
Comment 241 daxcore 2019-08-07 18:47:21 UTC
(In reply to Takashi Iwai from comment #230)
> (In reply to daxcore from comment #229)
> > completely not working here. also not patch 7. with pa sound is jumping,
> and
> > with alsa I just get a random noise.
> > 
> > does this work for anybody with X399 board alc1220?
> 
> That sounds like a different problem.  Especially a random noise shouldn't
> be caused by the DMA position bug.  Try to clear the audio setup once.
> 
> Does the audio work on any other OS at all?

In windows 10 the sound works fine.
I guess for X399 boards there is another issue. Non of the patches changed anything here. however, thanks!
Comment 242 Luca Osvaldo M. 2019-08-07 19:52:29 UTC
(In reply to Takashi Iwai from comment #227)
> Created attachment 284221 [details]
> Test fix patch no.7

completely fixed the audi for me, ALC 892 + MSI B350M

Same tests as before, sound playback works fine as long I'm in a discord channel (the patch 6 only fixed the microphone)
Comment 243 Takashi Iwai 2019-08-07 20:23:57 UTC
(In reply to Ernst Sjöstrand from comment #240)
> (In reply to Takashi Iwai from comment #237)
> > What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1],
> > together with dropping SNDRV_PCM_INFO_BATCH flag?  Still getting the same
> > problem?
> 
> I getting the crackling mic input if I do that yes.

And you didn't get the same crackling mic input with patch no.2?
If so, there are still two differences:
- The patch2 calculates the delay from the register
- The patch2 applies the delay also for the playback

But the second point shouldn't influence on the recording quality.  Then it's about the first point, and it can be changed like:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -866,8 +866,8 @@ static unsigned int azx_get_pos_fifo(struct azx *chip, struct azx_dev *azx_dev)
 	if (!runtime)
 		return pos;
 
-	runtime->delay = AMD_FIFO_SIZE;
-	delay = frames_to_bytes(runtime, AMD_FIFO_SIZE);
+	delay = snd_hdac_stream_readw(azx_stream(azx_dev), SD_FIFOSIZE) + 1;
+	runtime->delay = bytes_to_frames(runtime, delay);
 	if (azx_dev->insufficient) {
 		if (pos < delay) {
 			delay = pos;


FWIW, the second point can be changed even more simply.

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -878,7 +878,7 @@ static unsigned int azx_get_pos_fifo(struct azx *chip, struct azx_dev *azx_dev)
 	}
 
 	/* correct the DMA position for capture stream */
-	if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) {
+	if (1 /*substream->stream == SNDRV_PCM_STREAM_CAPTURE*/) {
 		if (pos < delay)
 			pos += azx_dev->core.bufsize;
 		pos -= delay;


Let us know if any of these (with/without the get_delay disablement) makes improvement.
Comment 244 Ernst Sjöstrand 2019-08-07 21:25:04 UTC
So with patch 7, but tsched=1 (ie. not the part with |= BATCH included) I get the following:

Only test idea 1: crackling
1+2: no crackling but playback skips when start/stop recording
2: no crackling but playback skips when start/stop recording

I retested patch 2 and realized I also have that behavior there: no crackling but playback skips when start/stop recording.
Comment 245 al 2019-08-08 05:32:51 UTC
I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220.

Audio output works fine but input is cracking and distorted. 

I tried with patch #2 and patch #7 and no luck on my end. If there is any more information I can provide to be helpful please let me know.

Here is my alsa-info 

http://alsa-project.org/db/?f=900284a51fd5498509bd04653f7b3d653fafa21d
Comment 246 Takashi Iwai 2019-08-08 06:25:42 UTC
(In reply to Ernst Sjöstrand from comment #244)
> So with patch 7, but tsched=1 (ie. not the part with |= BATCH included) I
> get the following:
> 
> Only test idea 1: crackling
> 1+2: no crackling but playback skips when start/stop recording
> 2: no crackling but playback skips when start/stop recording
> 
> I retested patch 2 and realized I also have that behavior there: no
> crackling but playback skips when start/stop recording.

So, if we delay the playback, too, it works, but it suffers from the stall, too.  Interesting.
Comment 247 Takashi Iwai 2019-08-08 06:27:26 UTC
(In reply to al from comment #245)
> I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220.
Judging from alsa-info.sh output, your device has a different PCI device ID, 1022:1487.  Replace the entry and retest.
Comment 248 al 2019-08-09 00:16:03 UTC
(In reply to Takashi Iwai from comment #247)
> (In reply to al from comment #245)
> > I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220.
> Judging from alsa-info.sh output, your device has a different PCI device ID,
> 1022:1487.  Replace the entry and retest.

Thanks that did it works great now!
Comment 249 Takashi Iwai 2019-08-09 09:26:12 UTC
(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.
Comment 250 al 2019-08-09 15:52:25 UTC
(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.

Ok thanks, I tested with discord and load-module module-loopback and it works perfectly.

But with steam I tested my voice for the first minute of testing I sound like a demon, and in valve games the mic is still distorted. 

Any info I can provide?
Comment 251 Marco 2019-08-09 18:15:26 UTC
(In reply to al from comment #250)
> (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.
> 
> Ok thanks, I tested with discord and load-module module-loopback and it
> works perfectly.
> 
> But with steam I tested my voice for the first minute of testing I sound
> like a demon, and in valve games the mic is still distorted. 
> 
> Any info I can provide?

That is unfortunately correct, in Steam Voice Chat the audio is still stuttering like crazy :S
Comment 252 Ernst Sjöstrand 2019-08-09 23:45:40 UTC
No issues here with Steam Voice Chat with patch 7 on 1022:1457.
Comment 253 Marco 2019-08-10 13:52:44 UTC
(In reply to Marco from comment #251)
> (In reply to al from comment #250)
> > (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.
> > 
> > Ok thanks, I tested with discord and load-module module-loopback and it
> > works perfectly.
> > 
> > But with steam I tested my voice for the first minute of testing I sound
> > like a demon, and in valve games the mic is still distorted. 
> > 
> > Any info I can provide?
> 
> That is unfortunately correct, in Steam Voice Chat the audio is still
> stuttering like crazy :S

The stutters remains only for one minute after activating the webrtc stream on Steam, afterwards the audio clears up and, besides a long delay of around 1/2 of a second, the audio is clear.
Comment 254 Luca Osvaldo M. 2019-08-11 11:25:06 UTC
That's true, Steam Voice Chat has distortions/delays for 1 minute (but totally different than the usual like it was on Discord) 
Also, my voice has a much lower pitch too, and only for one minute. 

But I noticed this is happening on Discord too right when I join a channel (or do a voice self test) for 2 seconds.
Comment 255 Marco 2019-08-11 16:24:40 UTC
(In reply to Luca from comment #254)
> That's true, Steam Voice Chat has distortions/delays for 1 minute (but
> totally different than the usual like it was on Discord) 
> Also, my voice has a much lower pitch too, and only for one minute. 
> 
> But I noticed this is happening on Discord too right when I join a channel
> (or do a voice self test) for 2 seconds.

Not for me, on discord the audio is perfect. I still don't get where the problem lies here.
Comment 256 Khaled 2019-08-15 10:33:35 UTC
I have MSI A320m mobo with a Realtek ALC887 and got the same problem not sure if others are having another problem with this chip but if i connect a speakers to the rear panel and a headset to the front panel it only detects my front panel it even says "unplugged" in audio settings i have to unplug the headset to get audio from the speakers no hardware problems since it works just fine on Windows 10
Comment 257 Ernst Sjöstrand 2019-08-15 12:18:25 UTC
(In reply to Khaled from comment #256)
> I have MSI A320m mobo with a Realtek ALC887 and got the same problem not
> sure if others are having another problem with this chip but if i connect a
> speakers to the rear panel and a headset to the front panel it only detects
> my front panel it even says "unplugged" in audio settings i have to unplug
> the headset to get audio from the speakers no hardware problems since it
> works just fine on Windows 10

This is not related to crackled sound capture.
Comment 258 Khaled 2019-08-15 20:05:39 UTC
(In reply to Ernst Sjöstrand from comment #257)
> (In reply to Khaled from comment #256)
> > I have MSI A320m mobo with a Realtek ALC887 and got the same problem not
> > sure if others are having another problem with this chip but if i connect a
> > speakers to the rear panel and a headset to the front panel it only detects
> > my front panel it even says "unplugged" in audio settings i have to unplug
> > the headset to get audio from the speakers no hardware problems since it
> > works just fine on Windows 10
> 
> This is not related to crackled sound capture.

I know it's not but just wanted to mention it since i can't find a bug report about it plus i am sure the same people that are affected by crackled sound capture are affected by this one as well
Comment 259 Luca Osvaldo M. 2019-08-16 08:58:22 UTC
(In reply to Khaled from comment #256)
> I have MSI A320m mobo with a Realtek ALC887 and got the same problem not
> sure if others are having another problem with this chip but if i connect a
> speakers to the rear panel and a headset to the front panel it only detects
> my front panel it even says "unplugged" in audio settings i have to unplug
> the headset to get audio from the speakers no hardware problems since it
> works just fine on Windows 10

Before filling a bug in the kernel bugzilla you should check if that happens with Alsa only
Comment 260 Dmitriy 2019-08-20 19:31:14 UTC
Asus A88X-Pro (Realtek 1150)
I join the problem in Discord
Comment 261 Vinay Shastry 2019-08-21 08:01:35 UTC
Distortion/crackled sound in steam voice chat started with kernel 5.2.9.
Differently distorted sound in discord web - parts of voice is chopped off every half second or so, and a large lag - 1 second or so.

Everything works fine in 5.2.8.


Board: ASUS PRIME X370-PRO.
lspci -nn extract:
0c:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller [1022:1457]


Is there a way to disable this patch - with a bootparam perhaps?
Comment 262 Vinay Shastry 2019-08-21 17:31:24 UTC
(In reply to Vinay Shastry from comment #261)
> Everything works fine in 5.2.8.

Actually, scratch that. I never tried the mic port until today (didn't have a mic). The crackling is present as reported by others.


In 5.2.9, there is a different kind of distortion when using a usb webcam's mic for input + onboard sound card for output on steam voice chat.
This new distortion issue wasn't present in 5.2.8 with webcam mic.
Comment 263 daxcore 2019-08-22 04:44:55 UTC
(In reply to Vinay Shastry from comment #261)
> Distortion/crackled sound in steam voice chat started with kernel 5.2.9.
> Differently distorted sound in discord web - parts of voice is chopped off
> every half second or so, and a large lag - 1 second or so.
> 
> Everything works fine in 5.2.8.
> 
> 
> Board: ASUS PRIME X370-PRO.
> lspci -nn extract:
> 0c:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h
> (Models 00h-0fh) HD Audio Controller [1022:1457]
> 
> 
> Is there a way to disable this patch - with a bootparam perhaps?

So sounds like I am back in business, I never tried a kernel version lower than 5.3.
Comment 264 John W. 2019-08-26 22:42:23 UTC
Just chiming in: I applied the upstream patch[1] with success on my older-kernel system.

It fixed the audio crackle issue on my line-in — thanks Takashi Iwai (:

Mobo: ASus X570 Phantom Gaming 4
Audio chipset: ALC1200 (1022:1457)
Kernel: 4.19.0
OS: Debian 10

[1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=af9d64f871cfe441508f116f31b49410453f96db
Comment 265 Térence Clastres 2019-08-27 20:22:13 UTC
(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.

I can't find this entry in the commit. Did you forget or added it in another one?
Comment 266 alpir 2019-08-28 11:57:30 UTC
ASRock Fatal1ty B450 Gaming K4
ALC892, [1022:1457] subsys [1849:9893] 

With patch no.7 with kernel 4.19.66 and telegram-desktop-bin-1.8.2 my companion hear myself.

With patch No. 5 there is no such problem and no crackling.
Comment 267 Ernst Sjöstrand 2019-08-28 12:27:15 UTC
So you can have different $THING ALC1220 vs ALC892 but still the same pciid 1022:1457 ...
Comment 268 alpir 2019-08-28 12:34:13 UTC
(In reply to Ernst Sjöstrand from comment #267)
> So you can have different $THING ALC1220 vs ALC892 but still the same pciid
> 1022:1457 ...

But the driver is the same one used.
Comment 269 Takashi Iwai 2019-08-29 12:55:29 UTC
For all people who still see the problem: please test 5.3-rc6 or rc7 kernel and confirm that the problem persists.

Once after confirming the same issue with 5.3-rc7, and it's about the PCI device 1022:1457 or 1022:1487, then check the following:

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

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -887,7 +887,7 @@ static int azx_get_delay_from_fifo(struct azx *chip, struct azx_dev *azx_dev,
 	struct snd_pcm_substream *substream = azx_dev->core.substream;
 
 	/* just read back the calculated value in the above */
-	return substream->runtime->delay;
+	return 0; // return substream->runtime->delay;
 }
 
 static unsigned int azx_skl_get_dpib_pos(struct azx *chip,


2. Change the return value of azx_get_delay_from_fifo() to 0 only for playback, e.g.
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -887,7 +887,9 @@ static int azx_get_delay_from_fifo(struct azx *chip, struct azx_dev *azx_dev,
 	struct snd_pcm_substream *substream = azx_dev->core.substream;
 
 	/* just read back the calculated value in the above */
-	return substream->runtime->delay;
+	if (substream->stream == SNDRV_PCM_STREAM_CAPTURE)
+		return substream->runtime->delay;
+	return 0;
 }
 
 static unsigned int azx_skl_get_dpib_pos(struct azx *chip,


3. Drop SNDRV_PCM_INFO_BATCH workaround in hda_controller.c

--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -613,12 +613,14 @@ static int azx_pcm_open(struct snd_pcm_substream *substream)
 				     20,
 				     178000000);
 
+#if 0
 	/* 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;
+#endif
 
 	if (chip->align_buffer_size)
 		/* constrain buffer sizes to be multiple of 128
Comment 270 Vinay Shastry 2019-09-01 07:30:28 UTC
(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.
Comment 271 Takashi Iwai 2019-09-01 08:28:49 UTC
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.
Comment 272 Vinay Shastry 2019-09-01 10:54:10 UTC
(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.
Comment 273 Takashi Iwai 2019-09-01 12:31:23 UTC
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.
Comment 274 al 2019-09-02 00:36:03 UTC
(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
Comment 275 Marco 2019-09-06 12:13:51 UTC
(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).
Comment 276 Marco 2019-09-06 19:26:59 UTC
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.
Comment 277 Alberto 2019-09-14 12:57:35 UTC
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
Comment 278 alpir 2019-09-16 05:32:24 UTC
(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]
Comment 279 Christopher Snowhill 2019-09-19 01:08:29 UTC
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
Comment 280 Takashi Iwai 2019-09-20 07:36:06 UTC
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
Comment 281 Alberto 2019-09-20 11:19:58 UTC
(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
Comment 282 Marco 2019-10-09 19:07:16 UTC
(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.
Comment 283 Benjamin Krippner 2019-10-27 18:03:29 UTC
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)?
Comment 284 Khaled 2019-11-26 07:21:23 UTC
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
Comment 285 Adam Reichold 2020-04-20 10:09:29 UTC
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.
Comment 286 Marco 2021-02-07 13:20:39 UTC
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.
Comment 287 Rob McCathie 2021-02-15 02:19:13 UTC
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.
Comment 288 Takashi Iwai 2021-02-15 08:13:26 UTC
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?
Comment 289 Takashi Iwai 2021-02-15 08:18:12 UTC
... 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...
Comment 290 Takashi Iwai 2021-02-15 08:51:26 UTC
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.
Comment 291 Rob McCathie 2021-02-15 16:58:02 UTC
@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.
Comment 292 Rob McCathie 2021-02-15 17:03:58 UTC
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.
Comment 293 Marco 2021-02-17 13:45:23 UTC
(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.
Comment 294 Takashi Iwai 2021-02-17 14:08:56 UTC
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.
Comment 295 Rob McCathie 2021-02-18 05:07:30 UTC
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.
Comment 296 Rob McCathie 2021-02-26 07:55:44 UTC
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.
Comment 297 Marco 2021-03-03 10:39:27 UTC
(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.
Comment 298 Takashi Iwai 2021-03-03 11:22:01 UTC
Yes, that's merely an ugly workaround, and I'd happily get rid of it once after confirming it's working fine without that!
Comment 299 Takashi Iwai 2021-03-08 16:06:16 UTC
OK, I'm going to submit this partial revert.
Comment 300 Takashi Iwai 2021-03-08 16:07:14 UTC
Created attachment 295735 [details]
The partial revert patch
Comment 301 Adrien Dessemond 2021-03-30 00:02:49 UTC
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.
Comment 302 Adrien Dessemond 2021-04-14 22:50:16 UTC
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...
Comment 303 Marco 2021-07-01 12:59:28 UTC
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.
Comment 304 Marco 2021-07-02 15:36:35 UTC
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.
Comment 305 haro41 2023-05-25 12:06:59 UTC
(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.
Comment 306 haro41 2023-05-25 12:12:50 UTC
Created attachment 304321 [details]
script to adapt alc3234 codec coefs
Comment 307 pshou 2023-05-29 10:35:27 UTC
Created attachment 304349 [details]
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: bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> 
Sent: Thursday, May 25, 2023 8:13 PM
To: Pshou <pshou@realtek.com>
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 haro41@gmx.de ---
Created attachment 304321 [details]
  --> 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.
Comment 308 Takashi Iwai 2023-06-05 09:08:22 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.