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-01-30 17:02 UTC (History)
24 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

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

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