Bug 195303 - ALC1220 snd_hda_intel Sound capture is crackled / distorted
Summary: ALC1220 snd_hda_intel 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: 2019-06-22 15:33 UTC (History)
41 users (show)

See Also:
Kernel Version: 4.11.0-rc5
Tree: Mainline
Regression: No


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
attachment-26498-0.html (1.43 KB, text/html)
2019-06-08 13:14 UTC, Anders
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

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

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