Audio playback seems to be fine, however audio capture results in crackling. - all values of position_fix have been tried and do not help - power_save=0 does not help - align_buffer_size does not help - enable_msi does not help Hardware is onboard ALC1220 codec sound chipset on the ASUS Crosshair VI Hero motherboard.
Created attachment 257067 [details] alsa-info of offending hardware
To elaborate on this bug: - I've found someone on reddit who went into more detail (including futile pulseaudio sorcery): https://www.reddit.com/r/linuxquestions/comments/68rirb/mic_cracklingstatic/ - He was kind enough to upload an audio sample: https://drive.google.com/open?id=0B1kXCJ6A8v29N3lBT0c4TGdRbFE I have encountered the same problem. It is present from 4.11 to 4.12.0-rc5 (most recent rc as of this writing). I tried a few distros; all have the same problem. Windows 10 records without distortion. This device identifies as "Vendor Id: 0x10ec1168". See attached alsa-info file and ignore the ATI HDMI and Audioengine noise as best as possible.
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
The same on 4.12.6 and previous, just tried.
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.
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.
@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.
(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.
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
(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 :)
(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 ;)
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.
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.
Created attachment 279083 [details] alsa-info of ASUS ROG STRIX X470-F GAMING
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.
Created attachment 279131 [details] ALSA INFO ASUS ROG X370-F Gaming
Getting the same on ALC892, the sound is robotic and distorted on high volume especially.
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.
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.
I have the same issue with an Gigabyte GA-AX370-Gaming K3 (ALC1220) on Kubuntu 18.04 with all sorts of Kernels tested.
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.
Created attachment 279567 [details] alsa-info of ASUS ROG Crosshair VI Hero Wifi (ALC1220)
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.
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.
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
Same problem on an Asus X470 Prime with an ALC1220. alsa_info here: http://www.alsa-project.org/db/?f=51d2767bf8486796b87abc616308089588ff2e43
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
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.
So it seems this would be a problem with resampling with pulseaudio on certain hardware then? Would that be correct?
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?
(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.
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.
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
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.
Yes I said that right before...
(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.
I'm about to just give up and buy a USB sound adapter. Anyone have any news on this?
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.
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.
(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
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
Created attachment 281641 [details] alsa-info of ASUS ROG STRIX X470-F GAMING
Created attachment 281661 [details] alsa-info of MSI MEG X399 CREATION same issue on MSI MEG X399 CREATION with ALC1220.
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
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?
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.
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.
(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.
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
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.
Same problem with a B450 chipset and a ALC892 on a B450 AORUS ELITE motherboard from Gigabyte.
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.
(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.
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.
(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.
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
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.
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.
After some testing with the PulseAudio folks, they have determined that the bugs relies on ALSA, just FYI.
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?
(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?
*alsa-user, sorry.
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?
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.
(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.
Still present in 5.1.3.
Still present in 5.1.5.
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.
(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.
(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).
(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.
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
(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.
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.
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?
(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
(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.
Created attachment 283153 [details] Alsainfo of Gigabyte B450 Aorus Elite
So could we try getting in touch with the HDA maintainers?
(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.
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.
(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.
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
Created attachment 283173 [details] VFIO trace of a problematic ALC892 on Windows VM
(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.
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.
(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).
Created attachment 283191 [details] VFIO log on linux after a reboot (codec in cold state)
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.
(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
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.
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.
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.
Created attachment 283389 [details] PCI raw commands sent by Windows to the audio codec
Created attachment 283391 [details] PCI raw commands sent by Linux to the audio codec
Some reports in the ubuntu bug file suggests this is also happening on old AMD platforms as well... With even different ALC codecs.
I'm also experiencing this issue on an MSI B450 Carbon Pro Gaming AC mobo with the ALC1220 codec. I can get the output crackling to stop somewhat using tsched=0, but my mic still experiences the issue. Works fine in Windows.
I submitted this bug over 2 years ago. It's pretty obvious at this point that it'll never get fixed. It's a shame all the board makers are using these realtek chips. I'd expect with their popularity some developer somewhere would have wanted it fixed. Do we have to take a collection for a bug bounty for someone to be interested in this? It might end up being cheaper than us all going out and buying USB DACs. Oh, wait, I already bought one.
Frédéric Pierret was the first here to identify a possible origin for the problem. And Marco did preliminary work on this. The "jcs way" looks promising to me, but surely it requires a lot of work. I'm joining you on the fact that we might never get help from Realtek on this, but I don't think we should disregard community's effort :) On my side, I also have a Realtek ALC1220 codec Codec: Realtek ALC1220 Vendor Id: 0x10ec1220 Subsystem Id: 0x18492220 Revision Id: 0x100101 equipped on an ASRock B450 Gaming-ITX/ac motherboard ("AMD Promontory B450" chipset). The sound coming out the green jack is OK. The sound recorded from the microphone plugged on the pink jack is crackling. I'm running Linux 4.19.44.
(In reply to Léo El Amri from comment #99) > ... > And Marco did preliminary work on this. The "jcs way" looks > promising to me, but surely it requires a lot of work. > ... Yea, I'm still trying to find the energy to begin to write a parser for the codec commands, but this will surely take quite a lot of time. Luckily on the ALC892 datasheets are available online, so even if it is a vendor defined command (assuming they exists, but I think that's the case) from Realtek, we should be able to identify it. The problem is that I can't find the strength to read ca 120 pages (between vendor and HDA spec) of commands right now and extrapolate a script to parse them :P Maybe later this year I'll be giving that a shot; but not right now. For now I'm adapting to use an external audio card; at least for voice chat, it's good enough for me.
(In reply to Marco from comment #100) > Yea, I'm still trying to find the energy to begin to write a parser for the > codec commands, but this will surely take quite a lot of time. This actually sounds like something I would be interested in working on. However I don't really have any experience working with low level audio like this. Are the dumps you gave for the ALC892?
(In reply to Benjamin Cheng from comment #101) > (In reply to Marco from comment #100) > > > Yea, I'm still trying to find the energy to begin to write a parser for the > > codec commands, but this will surely take quite a lot of time. > > This actually sounds like something I would be interested in working on. > However I don't really have any experience working with low level audio like > this. > > Are the dumps you gave for the ALC892? Yep, they are coming from my ALC892. If you want to try to create a script to parse them, be my guest :) The only issue on Windows is that after the dump, the audio stack from Windows wasn’t responding; however that should not be an issue, if it’s simply a state change from the driver at boot up.
Created attachment 283575 [details] linux pci data translated
Created attachment 283577 [details] winn pci data translated
Anders, looks like those two files are exactly the same? I think the Linux file didn't get uploaded.
Created attachment 283579 [details] linuxdecoded
Created attachment 283581 [details] windecoded
better now?
(In reply to Anders from comment #108) > better now? Thanks a lot, now I just need to go back reading the specs :P
Should this bug be renamed to something like "Sound capture is crackled with all snd_hda_intel codecs on AM4 platforms"?
Seems to affect playback as well (at least for me unless tsched=0, but even then get weird bugs), probably should be something like this: snd_hda_intel - Sound input/output is distorted on AM4 platforms using Realtek codecs.
(In reply to Jon from comment #111) > Seems to affect playback as well (at least for me unless tsched=0, but even > then get weird bugs), probably should be something like this: > > snd_hda_intel - Sound input/output is distorted on AM4 platforms using > Realtek codecs. This seems more in line with the problems in this thread, to me.
I was wondering about this as well. It looks like not everyone have the exact same issue. For example, I have problems with sound input only while other people reported sound problem with output as well. I tried to gather and resume the reports given until now. I hope I didn't made a mistake. The values "Yes", "No" and '"Same"' in the "Input" and "Output" columns means "Does have the issue", "Does not have the issue" and 'Reported "the same problem"' respectively. Reporter Input Output Codec Motherboard ================== ===== ====== ========= ==================================== icebalm[...] Yes No ALC1220 ASUS CROSSHAIR VI HERO Malte zu Klampen "Same" "Same" ? ASUS PRIME X370-PRO Luke Ricciolo Yes "Same" ALC1220 ASUS CROSSHAIR VI HERO Frédéric Pierret "Same" "Same" ALC1220 ASROCK X370 GAMING K4 thomasg "Same" "Same" ALC1220 ASUS PRIME X370-PRO Artem Hluvchynskyi ? Yes ALC1220 ASROCK X370 GAMING K4 henk717[...] Yes No ALC1220 MSI X370 Gaming Pro Carbon aeder.redea[...] Yes No ALC1220 ASUS ROG STRIX X470-F GAMING Sebastian Hofmann ? Yes ALC1220 ASUS ROG STRIX X370-F GAMING Luca "Same" "Same" ALC892 ? Axel "Same" "Same" ? Gigabyte X470 AORUS Parker H "Same" "Same" ? Taichi X370 Marten "Same" "Same" ALC1220 Gigabyte GA-AX370-Gaming K3 evilphish[...] Yes No ALC1220 ASUS ROG CROSSHAIR VI HERO WiFi Tomasz Pieczerak Yes No ALC1220 Gigabyte B450 AORUS PRO ben.schaaf[...] Yes No ALC887-VD ASUS PRIME B350-Plus spychodelics[...] "Same" "Same" ALC1220 ASUS PRIME X470-PRO Anders ? ? ? ASUS PRIME X370-PRO Rafael Rossi Yes Yes ALC1220 ASUS ROG STRIX X470-F GAMING daxcore[...] "Same" "Same" ALC1220 Micro-Star MEG X399 CREATION MS-7B92 wtravisjones[...] "Same" "Same" ALC1220 ASRock B450 Gaming-ITX/ac ZigZag "Same" "Same" ? ASUS ROG Strix B450-F George Gibbs "Same" "Same" ? ASUS ROG CROSSHAIR VI HERO Marco "Same" "Same" ALC892 Gigabyte B450 AORUS ELITE Benjamin Cheng Yes ? ? ASUS PRIME X470-PRO Jon "Same" Yes ALC1220 MSI B450 Carbon Pro Gaming AC Léo El Amri Yes No ALC1220 ASRock B450 Gaming-ITX/ac
Well, another update that probably will be the last one from me, since I'm beginning to really hate ALSA. Decided today to try to test some parameters; I had left the audio card loaded with VFIO module since the command dump. Today I've decided to retry to use it, so I've removed the VFIO stubs from modprobe, rebooted and... no PCI audio card. Disabled IOMMU to force load the modules (something like this was already seen by me; even when VFIO wasn't asked to bind it, it would bind it anyway), no PCI audio card. lsmod says that the module is loaded on the audio card, however no audio from any PCI devices, even the audio from the GPU. I'll attach alsa-info. Just for reference on your list, when the module was working, I had output working fine, but input crackling.
Created attachment 283619 [details] alsa-info now completely ignores my PCI audio cards
Tried everything, including downgrade to a previous kernel, same behavior. The only thing I get in dmesg now is: [ 3.146686] hdaudio hdaudioC0D0: Unable to bind the codec [ 3.150739] hdaudio hdaudioC1D0: Unable to bind the codec Really useful.
After purging VFIO finally the PCI audio cards works again even after reenabling it. However now from the front panel only the right channel works from the front jack, from the back both works correctly. I don't really understand anything now; nor what the problem is. I'll try to replay some interesting commands from the decoded win dump, hoping for the best; however with all this random problems popping up, I'll really doubt that I will be able to fix anything.
Same Bug on Manjaro with kernel 5.2 and the MSI X370 Titanium / ALC1220
I have the same problem, input crackling, output ok. My setup: ASUS PRIME X470-PRO (ALC1220, latest bios 5007), Ryzen 2700X, 32GB ECC RAM, Kernel 4.19.58. This is really annoying, I'm using a USB dongle for mic input as workaround, but the SNR is not as good as the onboard audio. Tried to fiddle with ALSA kernel module param and pulse audio param, without success.
Same here. Running on Asus Rog Strix b350-f Gaming. OS: Ubuntu 19.04 - Kernel 5.0.20 - Gnome 3.32 Noticed that when I use Xorg, my input from webcam works out of the box on discord. Now on wayland I need to set tsched=0. Looking at the syslog says that discord was trying to use 48kHz instead of the default 44.1kHz. Already tryied to set "alternative frequency" to 44.1kHz like the default frequency, without success. Now using a usb audio to workaround.
Created attachment 283631 [details] alsa-info on MSI X370 Krait Gaming (MS-7A33) Adding alsa-info, same problem as everyone else - playback is perfect, mic recording crackles. This seems like a rather popular chipset, are we all gonna have to buy USB dongles?!
Created attachment 283647 [details] alsa-info on MSI B450 TOMAHAWK (with Realtek ALC892) I also had the same problem with the MSI B450 Tomahawk and Ryzen 2600, I managed some time ago to make the audio output sound acceptable but the mic in default config makes a lot of noise, and after configuring pulse there's still a static noise constantly running, I had to resort to buying a cheap USB Audio Card. I also reported some time ago that I had audio issues on another thread relative to the ALC892.
Just adding to the list of people noting that the ALC1220 has problems as well. I have an MSI MPG X570 Gaming Edge Wifi board, with the newest X570 chipset. The audio is unusable because of this bug - a very noticeable crackle on the input side. Output is OK. The volume of the microphone input is insanely loud - it seems to be WAY to highly amplified. Ah well, the old soundblaster will live on into the new machine I guess.
Manjaro 18.04 with kernel 4.19, Asrock B350 Gaming ITX/ac, Ryzen 1600, Realtek ALC1220. Both input and output are with crackling. After some tweaks in pulse daemon (changing in sample rate) input cracks are gone, but in output its still here. Also this fixes are heavy on CPU, resulting in stutters in mediacontent and gaming.
Well, it's still not clear who to blame. Practically seen, the problem appears on a certain Realtek codecs just because there are such codec chips on the market for major mobos. Except for a few vendors (like Apple), all boards are equipped with Realtek codecs. So, I still suspect the problem being in HD-audio controller -- the AMD chipset side. Can people check whether any of workarounds have any effect? For example, - Make sure the existing quirks for ATI boards: Check the PCI device ID of your HD-audio controller connected to the onboard analog audio. You may have multiple HD-audio controller entries, and one of them is for HDMI and another for the onboard audio. The table in sound/pci/hda/hda_intel.c indicates the type and the quirk. The AMD one should be with AZX_DCAPS_PRESET_ATI_SB. - Disable the page caching. This can be done by passing snoop=0 option. But maybe it's more interesting to forcibly disable the cache while keeping the PCI snoop enabled, e.g. apply a patch like: --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1681,6 +1681,7 @@ static int azx_create(struct snd_card *card, struct pci_dev *pci, chip->single_cmd = single_cmd; azx_check_snoop_available(chip); + chip->uc_buffer = true; // XXX if (bdl_pos_adj[dev] < 0) - Adjust more quirk bits: AZX_DCAPS_PRESET_ATI_SB contains AZX_DCAPS_NO_TCSL. Try to remove this flag, for example. Also, add more flags, e.g. AZX_DCAPS_NO_MSI, AZX_DCAPS_NO_MSI64, AZX_DCAPS_NO_64BIT, AZX_DCAPS_4K-BDLE_BOUNDARY. - Try different sample rates, format, period and buffer sizes: At best test with aplay / arecord with -Dhw option to skip pulseaudio. (You can run it over pasuspender.) Check various parameters, e.g. 44.1k vs 48kHz, S16_LE vs S32_LE. Try to align the period size and the buffer size to be 4kB.
Thanks for the pointer Tiwai! The problem on my board at least seems to be AZX_DCAPS_POSFIX_LPIB, which seems to get enabled by default. Some of the HDMI entries further down? My chip is called 1022:1457 so I did something like this: /* AMD X370 */ { PCI_DEVICE(0x1022, 0x1457), .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_NO_TCSEL | AZX_DCAPS_SYNC_WRITE | AZX_DCAPS_SNOOP_TYPE(ATI) }, Not sure what to call the entry. I didn't notice any change with SYNC_WRITE on or off really. Here's a way to list the pciid of you sound chip btw: lspci | grep "HD Audio" | cut -d " " -f 1 | xargs sudo lspci -n -s
Hm, interesting, AZX_DCAPS_POSFIX_LPIB basically sets the position reporting based on LPIB instead of the position buffer. I thought the position buffer isn't available or unreliable on non-Intel chips, but it might be different on the recent AMD one. FWIW, you can change the behavior via position_fix option, too. This is an array for multiple instances, so be careful if you have multiple HD-audio devices (likely on AMD). If you pass a non-default value (e.g. 2, which means to forcibly use the position buffer) to the second card, pass like position_fix=,2 note the comma before "2". AZX_DCAPS_SYNC_WRITE should be likely OK. It essentially enables the sync after each write for the codec communication stability, i.e. it assures each command verb is executed and waiting for the response of that command. We're going to enable this flag even for Intel chipsets, too.
(In reply to Takashi Iwai from comment #127) > Hm, interesting, AZX_DCAPS_POSFIX_LPIB basically sets the position reporting > based on LPIB instead of the position buffer. I thought the position buffer > isn't available or unreliable on non-Intel chips, but it might be different > on the recent AMD one. Contrary to what Ernst experienced, removing AZX_DCAPS_POSFIX_LPIB completely broke audio on my system (ASUS PRIME X470, also 1022:1457), so I guess it's still unreliable as you mentioned. Was looking through the pci_ids array in sound/pci/hda/hda_intel.c and noticed that my audio controller (1022:1457) isn't listed. The only thing I can see that would match is the following, which seems to be intended for AMD GPUs. { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_ANY_ID), .class = PCI_CLASS_MULTIMEDIA_HD_AUDIO << 8, .class_mask = 0xffffff, .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI },
That's bad that the chipset shows inconsistent behavior. How did you test exactly and how it's broken without AZX_DCAPS_POSFIX_LPIB? As mentioned in comment 125, the first thing to do is to assure your PCI device listed in the azx_ids[] table explicitly. If not, create an entry to pass like: .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB This should be defined before the generic catch-all entry mentioned in comment 128. I guess this entry addition won't suffice by itself, but this at least aligns with the older AMD chipset, and we can test by adjusting the AZX_DCAPS_PRESET_ATI_SB definition. Then try other parameters mentioned in comment 125, or play with AZX_DCAPS_POSFIX_* or position_fix option.
Created attachment 283955 [details] 1022 1457 patch Here's exactly what I did, on a 5.2.0-rc5 base. Note that it's just AZX_DRIVER_GENERIC and then the contents of ATI_SB without AZX_DCAPS_POSFIX_LPIB.
Hmm ok I didn't test very properly, the crackle is gone but there seems to be some timing issues with playback, it doesn't sound correctly anymore. :-)
Then possibly the playback needs LPIB while the capture position buffer? A patch like below...
Created attachment 283961 [details] A test patch for PCI 1022:1457
Tried the patch on kernel 4.19.60, no sound on input.
(In reply to David from comment #134) > Tried the patch on kernel 4.19.60, no sound on input. Here it is working (5.2.2), but it's worse than before. I will try to play with parameters now. Thanks for the base patch, Tiwai. I'll see if with some parameters above something will change. However, right now the left channel from my front headphone jack is still not working.
Tried quite a lot of different combination of quirks and older or latest bios with the provided patch, nothing helps. The noise frequency changes, but it is still unusable.
(In reply to Takashi Iwai from comment #132) > Then possibly the playback needs LPIB while the capture position buffer? > A patch like below... Nope, that didn't work. Playback was fine and recording was still crackling. Is everyone affected here on 1022:1457 btw?
(In reply to Ernst Sjöstrand from comment #137) > (In reply to Takashi Iwai from comment #132) > > Then possibly the playback needs LPIB while the capture position buffer? > > A patch like below... > > Nope, that didn't work. Playback was fine and recording was still crackling. > > Is everyone affected here on 1022:1457 btw? From me yes, but if you check the posted alsa-config, most of them are 1022:1457. Mine is the same.
Any additional option that we can try to fix this issue, besides trying to contact AMD again for the chipset docs?
Please write down exactly what you've tested. Otherwise we can't reduce the possible causes.
(In reply to Takashi Iwai from comment #140) > Please write down exactly what you've tested. Otherwise we can't reduce the > possible causes. Tested the posted patch from you, same issue. Tried to enable all DCAPS flags (except SNOOP_MASK, SNOOP_ON, because I had used as a base the patch in attachment 283955 [details] that had already enabled SNOOP_TYPE(ATI); and I915_COMPONENT (since I do not have an integrated Intel iGPU)) on the codec specified inside line 20-47 in hda_controller.h, same issue persists. I don't really know where to proceed. The only change is in the noise frequency in time, it's more frequent or less, but the issue is still there.
Created attachment 284085 [details] Test patch with all DCAPS enabled for 1022:1457
The crucial point isn't about the DCAPS changes. Rather other points, e.g. setting the non-cache mode *in addition* to the DCAPS changes, trying with different formats, rates, period/buffer sizes on the modified setup, etc. And all these combos. Basically, adding putting DCAPS* flags don't make sense because some of them are mutual exclusive. Rather what I asked is to test to enable each DCAPS_* one by one. But this test doesn't look so promising, so it'd be needed only to make sure for now. Also, position_fix and bdl_pos_adj are another interesting parameters. The test patch recently provided was based on the information about the position_fix matters... Above all, the primary tests must be done via aplay/arecord with -Dhw option, not with PulseAudio. *** What we need to know at this point is whether the problem happens at transferring the data itself, the update timing problem, or some problem in the codec side. The common problems in the past are mostly the first two items: the first one is usually influenced by the memory cache coherency, and the second one is the LPIB reporting / position buffer instability or the FIFO size management. Both might be mixed together, too. I mentioned to test with aplay/arecord because PA is very sensible especially about the second (timing) problem. If aplay/arecord -Dhw with a large buffer and period works, it implies that the data transfer itself is fine, for example. So, we still need to gather the facts. For that, the precise information about *what* you tested is important. "I tested all" doesn't give you any clue, after all ;)
(In reply to Takashi Iwai from comment #143) > The crucial point isn't about the DCAPS changes. Rather other points, e.g. > setting the non-cache mode *in addition* to the DCAPS changes, trying with > different formats, rates, period/buffer sizes on the modified setup, etc. > And all these combos. > > Basically, adding putting DCAPS* flags don't make sense because some of them > are mutual exclusive. Rather what I asked is to test to enable each DCAPS_* > one by one. But this test doesn't look so promising, so it'd be needed only > to make sure for now. > > Also, position_fix and bdl_pos_adj are another interesting parameters. The > test patch recently provided was based on the information about the > position_fix matters... > > Above all, the primary tests must be done via aplay/arecord with -Dhw > option, not with PulseAudio. > > *** > > What we need to know at this point is whether the problem happens at > transferring the data itself, the update timing problem, or some problem in > the codec side. > > The common problems in the past are mostly the first two items: the first > one is usually influenced by the memory cache coherency, and the second one > is the LPIB reporting / position buffer instability or the FIFO size > management. Both might be mixed together, too. > > I mentioned to test with aplay/arecord because PA is very sensible > especially about the second (timing) problem. If aplay/arecord -Dhw with a > large buffer and period works, it implies that the data transfer itself is > fine, for example. > > So, we still need to gather the facts. For that, the precise information > about *what* you tested is important. "I tested all" doesn't give you any > clue, after all ;) Found a combination of parameters that seems to fix the issue with arecord, at least for 30 seconds, regardless of the sample rate (eg. 44100, 48000 or 192000, all now are clear recordings) is: pasuspender -- arecord -D hw:1,0 -f S32_LE -r44100 -d 10 -N -c 2 /tmp/test.wav The key parameters required are S32_LE as a format and the non blocking mode -N, otherwise the issue is still present. I hope that this will help to track down the issue. If other people here want to try it out to see if this fix their audio problems, that would be useful as well.
Hm, that's werid. Basically non-blocking mode matters only at opening the PCM device (whether the stream is busy or not), and it shouldn't influence on the running stream. Maybe it's a timing issue, like other tests failed sometimes... Did you already try using non-cached buffer in addition to the ATI-SB snooping? Try the change like the below: --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1986,7 +1986,7 @@ static int dma_alloc_pages(struct hdac_bus *bus, { struct azx *chip = bus_to_azx(bus); - if (!azx_snoop(chip) && type == SNDRV_DMA_TYPE_DEV) + if (/*!azx_snoop(chip) &&*/ type == SNDRV_DMA_TYPE_DEV) type = SNDRV_DMA_TYPE_DEV_UC; return snd_dma_alloc_pages(type, bus->dev, size, buf); } @@ -2002,7 +2002,7 @@ static void pcm_mmap_prepare(struct snd_pcm_substream *substream, #ifdef CONFIG_X86 struct azx_pcm *apcm = snd_pcm_substream_chip(substream); struct azx *chip = apcm->chip; - if (chip->uc_buffer) + if (1 /*chip->uc_buffer*/) area->vm_page_prot = pgprot_writecombine(area->vm_page_prot); #endif }
(In reply to Takashi Iwai from comment #145) > Hm, that's werid. Basically non-blocking mode matters only at opening the > PCM device (whether the stream is busy or not), and it shouldn't influence > on the running stream. Maybe it's a timing issue, like other tests failed > sometimes... > > Did you already try using non-cached buffer in addition to the ATI-SB > snooping? > Try the change like the below: > > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -1986,7 +1986,7 @@ static int dma_alloc_pages(struct hdac_bus *bus, > { > struct azx *chip = bus_to_azx(bus); > > - if (!azx_snoop(chip) && type == SNDRV_DMA_TYPE_DEV) > + if (/*!azx_snoop(chip) &&*/ type == SNDRV_DMA_TYPE_DEV) > type = SNDRV_DMA_TYPE_DEV_UC; > return snd_dma_alloc_pages(type, bus->dev, size, buf); > } > @@ -2002,7 +2002,7 @@ static void pcm_mmap_prepare(struct snd_pcm_substream > *substream, > #ifdef CONFIG_X86 > struct azx_pcm *apcm = snd_pcm_substream_chip(substream); > struct azx *chip = apcm->chip; > - if (chip->uc_buffer) > + if (1 /*chip->uc_buffer*/) > area->vm_page_prot = pgprot_writecombine(area->vm_page_prot); > #endif > } Yes, the issue is still present. I've applied attachment 283955 [details] and your last patch together.
Without -N. With it the acquisition is perfect again.
OK, thanks, then this might indicate that the culprit is about the subtle timing issue, not about the cache problem. Just to be sure, could you try to pass bdl_pos_adj=64,64 option to snd-hda-intel module?
Also, did anyone try different position_fix options, e.g. 5,5 or 4,4? 4,4 should be equivalent with my previous test patch, so it's not expected to work. But it's still interesting to know whether the recording with such an option proceeds at all. If the stream can be recorded for the expected length, no matter whether it's noisy or not, it means that the position buffer does work in some level. OTOH, if the stream can't be recorded at all (e.g. you get the DMA or stall error), the position buffer is broken on AMD platform.
(In reply to Takashi Iwai from comment #148) > OK, thanks, then this might indicate that the culprit is about the subtle > timing issue, not about the cache problem. > > Just to be sure, could you try to pass bdl_pos_adj=64,64 option to > snd-hda-intel module? I feel dumb, I had some options inside modprobe that was fixing the issue with -N apparently. After wiping it out and setting the above parameter to 64,64, the issue is present regardless of the -N parameter. I'll try to change it until I'll get the same behavior as before, or play again with parameters until I can fix it properly?
No need for retest, bdl_pos_adj is merely a shot-in-the-dark, and likely breaks something else :)
(In reply to Takashi Iwai from comment #149) > Also, did anyone try different position_fix options, e.g. 5,5 or 4,4? > 4,4 should be equivalent with my previous test patch, so it's not expected > to work. > > But it's still interesting to know whether the recording with such an option > proceeds at all. If the stream can be recorded for the expected length, no > matter whether it's noisy or not, it means that the position buffer does > work in some level. OTOH, if the stream can't be recorded at all (e.g. you > get the DMA or stall error), the position buffer is broken on AMD platform. I can't believe it, it works now with position_fix = 3! I don't know if this was caused by the additional patch to the kernel, I'll probably try to remove it to see if it is still working with 3, but I had already tried all position fix and a heap of other stuff. The audio now is perfect, even with pulseaudio :) This is the result that you have requested anyway: 0: Same problem, no other issues 1: Same problem, no other issues 2: Unable to acquire stream, arecord signal overrun!!! (at least 377,780 ms long) and no audio is acquired 3: No clicking in the acquired stream! 4: Same problem, no other issues
It's a good news. 3 is a workaround for VIA chip, but this seems applicable to AMD, then. The only concern is whether the AMD chip really provides the right FIFO size by the register read for VIA. Could you check which value is shown by the patch below? If it's 32 or some reasonable number, it's fine. --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1467,6 +1467,9 @@ static void assign_position_fix(struct azx *chip, int fix) azx_get_delay_from_lpib; } + pr_info("XXX fifo_size = %d\n", + readw(azx_bus(chip)->remap_addr + + VIA_IN_STREAM0_FIFO_SIZE_OFFSET)); }
(In reply to Takashi Iwai from comment #153) > It's a good news. 3 is a workaround for VIA chip, but this seems applicable > to AMD, then. > > The only concern is whether the AMD chip really provides the right FIFO size > by the register read for VIA. Could you check which value is shown by the > patch below? If it's 32 or some reasonable number, it's fine. > > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -1467,6 +1467,9 @@ static void assign_position_fix(struct azx *chip, int > fix) > azx_get_delay_from_lpib; > } > > + pr_info("XXX fifo_size = %d\n", > + readw(azx_bus(chip)->remap_addr + > + VIA_IN_STREAM0_FIFO_SIZE_OFFSET)); > } I have the suspect that it doesn't, since it mentions a null pointer kernel dereference; module crash attached below.
Created attachment 284089 [details] Kernel Bug reported when trying to access VIA register on a AMD platform
Regardless, it works even without any patch with position_fix = 3 on the latest stable kernel, 5.2.5. I had already tried that but now it actually works. In the hope that this will help, Marco.
Latest addition, tsched=0 is still required to have decent audio acquisition, otherwise the audio is stretched in time. A lot. Otherwise, after setting that, the audio is perfect now.
My bad, it was a wrong place to peek the value. Below is a revised one. Also it shows the similar information that should be available in the stream data. This may spew many messages, so it's enough just to get a few messages at testing recording.
Created attachment 284091 [details] A patch to show the fifo size
Just to confirm that using `pasuspender -- arecord -D hw:1,0 -f S32_LE -r44100 -d 10 -N -c 2 /tmp/test.wav` I did manage to get good audio without any kernel patch (4.15.0-55-generic). I've only get left channel though. But that's same even in noisy signal.
(In reply to Takashi Iwai from comment #158) > My bad, it was a wrong place to peek the value. > > Below is a revised one. Also it shows the similar information that should > be available in the stream data. This may spew many messages, so it's > enough just to get a few messages at testing recording. This works, and yes, reported sizes makes sense. I don't really get why an AMD/AsMedia chipset is acting as a VIA one, but it does look like that that's the case. Output attached below.
Created attachment 284093 [details] FIFO sizes from a AMD chipset
OK, that looks more promising. Now I cooked two patches. The first one is to simply apply the existing VIA position fix to the AMD X370 platform (1022:1457). This should work like the test you've done now without any option. The second one is an attempt with simpler position fix, just reducing the fifo size. Give this a try instead of the first patch. There are adjustable knobs in the second patch, at azx_get_pos_amd() function; the first one is whether to apply the correction to the playback stream, too. Since there was a report about the playback stuttering, I enabled it here, but you can try to change it. The second knob is the fifo_size retrieval, whether to read from the same register as VIA, or from the SD stream register. The end result might be same, but we need experiments.
Created attachment 284097 [details] Test fix patch no.1
Created attachment 284099 [details] Test fix patch no.2
Wow! This is so good. "patch no.2" is working great, no need to set tsched=0 anymore with that one.
Tried the same patch #2 with "fifo_size = azx_dev->core.fifo_size;" instead. same good results. (tested both method on kernel 4.19.63)
OK, thanks. Could you try another one below, too? This should be a more correct way from API POV, passing the delay value instead of the direct correction of the position.
Created attachment 284111 [details] Test fix patch no.3
Created attachment 284113 [details] Test fix patch (revised) The previous one won't work, I'm afraid. This is the revised one (no.4).
I confirm that both version of the second patch work. On playback I had only some minor issues when the stream was starting, but after enabling the playback patch, they disappeared too. Without tsched=0 and without the playback patch, acquisition work perfectly fine, but not the output, is delayed in time again. Forgot to test it without tsched and playback and data from fifo directly and not from VIA register, but I can recompile it if it is needed. I think that both patches are needed, even if my playback issue wasn't that problematic. Testing n.4 shortly. Thanks a ton for your work.
Thanks. The problem with playback indicates that the delay correction isn't good for playback but only for capture. Below is yet another revised patch. It corrects the position report only for the capture, but takes the FIFO delay into account, too.
Created attachment 284117 [details] Test fis patch no.5
BTW, does anyone hit the problem on an AMD board with other PCI ID than 1022:1457?
(In reply to Takashi Iwai from comment #172) > Thanks. The problem with playback indicates that the delay correction isn't > good for playback but only for capture. > > Below is yet another revised patch. It corrects the position report only > for the capture, but takes the FIFO delay into account, too. Number 4 works perfectly with tsched=0, but not without, stutters again (delayed and crackled, probably from playback this time since you mentioned it). I'll test patch v5 and report back.
(In reply to Takashi Iwai from comment #174) > BTW, does anyone hit the problem on an AMD board with other PCI ID than > 1022:1457? Another thing, 1022:1457 is not used only on X370, but also on my B450, and probably on a lot of other board, like B350 and such. Just a remark for the comment mentioning only X370 over the PCI device :) Thanks again, Marco.
(In reply to Marco from comment #176) > (In reply to Takashi Iwai from comment #174) > > BTW, does anyone hit the problem on an AMD board with other PCI ID than > > 1022:1457? > > Another thing, 1022:1457 is not used only on X370, but also on my B450, and > probably on a lot of other board, like B350 and such. Just a remark for the > comment mentioning only X370 over the PCI device :) > > Thanks again, > > Marco. ID 1022:1457 also used for AMD X399.
1022:1457 also on my MSI AMD B350M, on ALC892 codec
Gigabyte X470 AORUS ULTRA ALC1220, [1022:1457] subsys [1458:a0c3] Test Fis Patch no.5 on kernel 5.1.5: - sound playback OK - sound recording OK ( crackling disappeared )
(In reply to Takashi Iwai from comment #172) > Thanks. The problem with playback indicates that the delay correction isn't > good for playback but only for capture. > > Below is yet another revised patch. It corrects the position report only > for the capture, but takes the FIFO delay into account, too. With tsched=0, everything is perfect. When tsched=0 is removed, the audio output is not crackling again, however ALL audio is retarded when the acquisition starts, to me it feels around 4/5 seconds. I had a player playing music in background and the whole stream jump back for that time; if i try to seek in another position the audio will seek only after the same 4/5 seconds. If I stop capturing audio, the playback sync back again and the playback is working correctly again. Very weird.
(In reply to Takashi Iwai from comment #173) > Created attachment 284117 [details] > Test fis patch no.5 Tested on 1022:1457 also on my MSI AMD B350M, on ALC892 codec, Kernel 5.2.5 Works fine, thanks. I'll try to build an ubuntu package with this kernel patch for 5.0
ASRock Fatal1ty B450 Gaming K4 ALC892, [1022:1457] subsys [1849:9893] Test Fis Patch no.5 with kernel 4.19.57: - sound playback OK - sound recording OK (no crackling)
(In reply to Luca from comment #181) > (In reply to Takashi Iwai from comment #173) > > Created attachment 284117 [details] > > Test fis patch no.5 > > Tested on 1022:1457 also on my MSI AMD B350M, on ALC892 codec, Kernel 5.2.5 > > Works fine, thanks. > > I'll try to build an ubuntu package with this kernel patch for 5.0 Oh sorry I spoke too soon! However, sound capture definitely works fine when tested on https://webcammictest.com/check-microphone.html (it didn't before this patch) However, the sound still crackles on both input/output when using Discord.
Then can anyone test the hack in comment 145 together with patch#5?
(In reply to Takashi Iwai from comment #184) > Then can anyone test the hack in comment 145 together with patch#5? Same behavior as without, with tsched is perfect, without the stream jump back in time here, but the audio is clean, as mentioned in comment 180.
I don't see any difference between patch 2a 2b 4 or 5. Capture or playback, tsched=0 or tsched=1. My chipset is X470, [1022:1457], ALC1220.
also not working for me with kernel 5.3rc2 (archlinux: linux-git) and patch no. 5. ALC1220 X399 MSI board [1022:1457].
For those with non-working systems: first off, make sure that you're really testing the patched kernel, e.g. put a printk() for checking. Then test without PulseAudio at first, with aplay/arecord (with -Dhw:0 or -Dhw:1, depending on the system). As in comment 144, try with or without -N.
(In reply to Marco from comment #180) > (In reply to Takashi Iwai from comment #172) > > Thanks. The problem with playback indicates that the delay correction > isn't > > good for playback but only for capture. > > > > Below is yet another revised patch. It corrects the position report only > > for the capture, but takes the FIFO delay into account, too. > > With tsched=0, everything is perfect. When tsched=0 is removed, the audio > output is not crackling again, however ALL audio is retarded when the > acquisition starts, to me it feels around 4/5 seconds. I had a player > playing music in background and the whole stream jump back for that time; if > i try to seek in another position the audio will seek only after the same > 4/5 seconds. If I stop capturing audio, the playback sync back again and the > playback is working correctly again. > > Very weird. So something goes wrong in the full-duplex operation? That is, if you do only capture or only playback, it works even without tsched workaround? Another shot-in-the-dark is to swap the stream assignment, something like: --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1853,8 +1853,8 @@ static int azx_first_init(struct azx *chip) break; } } - chip->capture_index_offset = 0; - chip->playback_index_offset = chip->capture_streams; + chip->playback_index_offset = 0; + chip->capture_index_offset = chip->playback_index_offset; chip->num_streams = chip->playback_streams + chip->capture_streams; /* sanity check for the SDxCTL.STRM field overflow */ It's unlikely that this has any effect, but who knows... Another quirk regarding the stream assignment is AZX_DCAPS_SEPARATE_STREAM_TAG flag, which is used for the recent Intel chips. Check whether it gives any positive changes.
(In reply to Takashi Iwai from comment #189) > (In reply to Marco from comment #180) > > (In reply to Takashi Iwai from comment #172) > > > Thanks. The problem with playback indicates that the delay correction > > isn't > > > good for playback but only for capture. > > > > > > Below is yet another revised patch. It corrects the position report only > > > for the capture, but takes the FIFO delay into account, too. > > > > With tsched=0, everything is perfect. When tsched=0 is removed, the audio > > output is not crackling again, however ALL audio is retarded when the > > acquisition starts, to me it feels around 4/5 seconds. I had a player > > playing music in background and the whole stream jump back for that time; > if > > i try to seek in another position the audio will seek only after the same > > 4/5 seconds. If I stop capturing audio, the playback sync back again and > the > > playback is working correctly again. > > > > Very weird. > > So something goes wrong in the full-duplex operation? That is, if you do > only capture or only playback, it works even without tsched workaround? > > Another shot-in-the-dark is to swap the stream assignment, something like: > > --- a/sound/pci/hda/hda_intel.c > +++ b/sound/pci/hda/hda_intel.c > @@ -1853,8 +1853,8 @@ static int azx_first_init(struct azx *chip) > break; > } > } > - chip->capture_index_offset = 0; > - chip->playback_index_offset = chip->capture_streams; > + chip->playback_index_offset = 0; > + chip->capture_index_offset = chip->playback_index_offset; > chip->num_streams = chip->playback_streams + chip->capture_streams; > > /* sanity check for the SDxCTL.STRM field overflow */ > > It's unlikely that this has any effect, but who knows... > > Another quirk regarding the stream assignment is > AZX_DCAPS_SEPARATE_STREAM_TAG flag, which is used for the recent Intel > chips. Check whether it gives any positive changes. Sorry, just noticed now, the input is not delayed, the signal on the screen is in sync with my voice, it's only the output that is retarded by 4 seconds. Trying now the DCAPS and then the patch supplied. Thanks again, Marco.
If you are on ArchLinux, I made a dkms package: https://aur.archlinux.org/packages/snd_hda_intel-alc1220-dkms/ which for now applies "Test fix patch no.2" as I found like others it was working well. I will certainly update it based on the reporters feedback from the different patches to try. Thanks a lot for your work Takashi Iwai!
Neither did nothing, however the audio playback has no problem staying in sync if I use directly arecord, even without pausing pulseaudio. So, it is a pulseaudio bug, if with arecord everything works correctly? Thanks a lot again, Marco.
It's hard to say whether it's a PA bug. I still doubt it being some inconsistent behavior of the driver, triggered only by some specific condition PA hits. Could you start PA with more verbosity and check whether PA complains anything at starting capture? It might be that the incorrect position screws up PA, or something like that.
Marco, I would like to try your issue on my side, can you share the step to reproduce the problem, maybe your default.pa file too.
Here is the pulseaudio log and the default.pa from my system, but the config (beside realtime scheduling) are unchanged:
Created attachment 284137 [details] pulseaudio log without tsched=0 when acquiring audio
Created attachment 284139 [details] My default.pa config file from pulseaudio
The only step is to not use tsched and try to use a software that use webrtc as a audio backend, like Discord. As soon as you test your mic, the audio in playback get shifted back in time, around 5 seconds. Thanks both for your time, Marco.
Marco, I see your issue with discord, there is a delay in the output when tsched=1. Sometime the sound get 'robotic', or there is a pre-echo and an echo, sometime the issue vanish when I play around with other application that capture or playback audio. This remind me a weird audio issue I had with my previous system (old core 2) in some steam game in the past, not sure if it's a kernel issue. [tested with patch #4 and #5 on kernel 4.19.63]
A possible explanation about the delay at playback while capturing is that the FIFO size reported for each stream is influenced by other action. The patch assumed that it's constant (like other platforms do), but AMD might vary it per state. The patch below (fix6) takes a hard-coded FIFO size. Check it out. There is one adjustment knob in the patch for an open question; whether the fixed FIFO size is in frames (samples) or in bytes, i.e. if the sample format changes from 32 to 16bit, whether FIFO size changes, too. If the patch was confirmed to work more or less, try to define/undefine AMD_FIXED_FIFO_IN_FRAMES, and check the behavior with S16 or S32 formats (on PA setup and/or aplay/arecord parameters).
Created attachment 284155 [details] Test fix patch no.6
Created attachment 284157 [details] The correct no.6 test patch Oops, sorry the previous no.6 was wrong. The correct one here.
(In reply to Takashi Iwai from comment #202) > Created attachment 284157 [details] > The correct no.6 test patch > > Oops, sorry the previous no.6 was wrong. The correct one here. Hi, I tested this patch and it seems to be working fine. 1) Test made at https://webcammictest.com/check-microphone.html, it works fine as the previous patch. This is a self hear test, everything works perfectly 2) Second test was made opening discord and using the builtin mic test, which also has a builtin self hear test. But, this time the output sound crackled for the first 3/4 seconds, then it was working fine. Unlike the previous patch where it was still present after that amount of time Kernel 5.2.5.
Hmm... I am noticing something strange between old and new kernels. Without any patch applied, on the kernel 5.2.5 as Marco said, is working fine after a couple of seconds (with or without position-fix=3) BUT a little bit of sound distortion is present without the Iwai patch 6. On older kernels than 5.2.5 like 4.19.63 the output issue "disappears" with Iwai's patch after a minute, so it takes longer. I think the issue is on the playback, because when I open Discord even the system audio crackles. But still I'm not sure. Is it possible newer kernels already have a partial workaround? I also noticed the patch modifies less lines on 5.2.5.
Another update, on kernel 4.19.63 with position_fix=3 the output crackling lasts 10 seconds. So to me it looks like that parameter is somehow "applied" to the 5.2.5 kernel by default??
(In reply to Takashi Iwai from comment #200) > A possible explanation about the delay at playback while capturing is that > the FIFO size reported for each stream is influenced by other action. The > patch assumed that it's constant (like other platforms do), but AMD might > vary it per state. > > The patch below (fix6) takes a hard-coded FIFO size. Check it out. > > There is one adjustment knob in the patch for an open question; whether the > fixed FIFO size is in frames (samples) or in bytes, i.e. if the sample > format changes from 32 to 16bit, whether FIFO size changes, too. > If the patch was confirmed to work more or less, try to define/undefine > AMD_FIXED_FIFO_IN_FRAMES, and check the behavior with S16 or S32 formats (on > PA setup and/or aplay/arecord parameters). Forgot to test with aplay without PA with the define disabled, however the acquired audio with PulseAudio was bad, like "low quality" (and the output was delayed as before). Using arecord (but not with PA disabled) I was hearing again a little of crackling. With the define the audio was perfect again with arecord (however only with PA disabled, I've tried to use aplay in another terminal while using arecord, however the audio is played back only when PA resumes; I'm not sure if this is something to be expected), same thing with PA; however the output was delayed again (when acquiring from PA). I've tested both S16 and S32 with the define and pulseaudio disabled, no problem heard.
Did you try to define AMD_FIXED_FIFO_IN_FRAMES in the patch, too? Also, try to increase the FIFO size defined there. The current value (256 bytes and 32 frames) is just a guess work and it might need larger size. And, the delay happens even with the patch no.6? Then my theory wasn't right, and it implies that the position reporting itself is delayed or the transfer is delayed by some reason. For analyzing it, we'd need the even tracing. Please try to get trace logs in /sys/kernel/debug/tracing/events/hda_controller while capturing and the retard playback. Some instructions are found in Documentation/sound/hd-audio/notes.rst.
Did some tests using the AUR package snd_hda_intel-alc1220-dkms (Seems to be Patch 2) on the 1022:1457 ALC1220 (X370 Pro Carbon motherboard). Using the default settings i no longer hear the robotic echo issues in my microphone recordings and i am able to get good recordings with Audacity. tsched=0 seems to have feint audio issues which are similar to my best case scenario without the patch. It is hard to hear and could be a tsched=0 only issue. However more worryingly i was able to reproduce my former Audacity "Dolphin speed" issue where it records way faster than it should. While not present by default this happens after i use pulseaudio -k and then try to use Audacity. This does not happen on my laptop with an Intel Motherboard and connexant audio chip indicating it is still driver related. The effect happens both on the "pulse" microphone and on the direct microphone when selected. Perhaps this is already resolved in the future patches, but i found this an easy to replicate testing scenario to see if underlying bugs are present.
(In reply to Takashi Iwai from comment #207) > Did you try to define AMD_FIXED_FIFO_IN_FRAMES in the patch, too? > Also, try to increase the FIFO size defined there. The current value (256 > bytes and 32 frames) is just a guess work and it might need larger size. > > And, the delay happens even with the patch no.6? Then my theory wasn't > right, and it implies that the position reporting itself is delayed or the > transfer is delayed by some reason. > > For analyzing it, we'd need the even tracing. Please try to get trace logs > in /sys/kernel/debug/tracing/events/hda_controller while capturing and the > retard playback. Some instructions are found in > Documentation/sound/hd-audio/notes.rst. Compiling a *4 in the parameters, I'll report back shortly. Yes, the only clean audio stream from PA and arecord was with the define enabled in the source code. If it doesen't change, i'll post a trace from the codec.
Nothing changed, here is the trace and the actions: 1) Opened VLC with a song 2) Opened discord 3) Started mic testing, output jumped back 5 seconds in the past 4) Ended mic testing, output re synced back. 5) Stopped VLC playing
Created attachment 284171 [details] Codec trace for the audio output delay problem
How does position_fix = 6 (the FIFO that the patch adds) work? Because when I add it, makes the system (only for GNOME) laggy when using Discord, exacly like before as I said in comment 86 https://bugzilla.kernel.org/show_bug.cgi?id=195303#c86 But this time obviously the mic capture is fine. Still in all those cases, the playback is distorted/robotic for a minute or so. But I remember the voice to be robotic months ago like this only when using Arch Linux??? (So an updated kernel, instead of the Ubuntu LTS I use right now) but since I used an USB card since now, I don't remember how the playback was working previously, I'm sure the microphone capture was still bad before this patch solved it
Discord being robotic can happen on functional audio cards as well, i for example had it on my laptop in the past. When subject to the real bug this does not clear up at all and will remain an issue for a while. The non related bug in discord itself i can usually get rid off by opening and closing other applications like my webbrowser and yes it does clear up on its own as well.
There's a lot to track here now, but patch #2 seems to work great here! Patch #6 didn't seem to cause any new problems for me, but the crackling is still there.
(In reply to Ernst Sjöstrand from comment #214) > There's a lot to track here now, but patch #2 seems to work great here! > > Patch #6 didn't seem to cause any new problems for me, but the crackling is > still there. 6 works only with the define enabled, remove the double slashes in front of #define, then it will work. Still, this works only with tsched=0 (which to me is good enough, honestly), but if we can fix even the last issue, that would be perfect.
(In reply to Marco from comment #211) > Created attachment 284171 [details] > Codec trace for the audio output delay problem Could you get the trace log for hda_controller, not hda? (/sys/kernel/debug/tracing/events/hda_controller) The former tracks the PCM events including the position report while the latter tracks only CORB/RIRB communications (i.e. the verb execution).
(In reply to Takashi Iwai from comment #216) > (In reply to Marco from comment #211) > > Created attachment 284171 [details] > > Codec trace for the audio output delay problem > > Could you get the trace log for hda_controller, not hda? > (/sys/kernel/debug/tracing/events/hda_controller) > > The former tracks the PCM events including the position report while the > latter tracks only CORB/RIRB communications (i.e. the verb execution). Whoops, my mistake. Here is the correct trace from hda_controller, same sequence of action taken:
Created attachment 284211 [details] hda_controller trace from the timing issue of my ALC892
Is this with tsched=0? I wonder why PA gets the position information so often. Without tsched change, PA should access to the hardware much less frequently. In anyway, one another interesting experiment is to reduce the max period size, something like below on top of the previous patch: --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -607,6 +607,7 @@ static int azx_pcm_open(struct snd_pcm_substream *substream) runtime->hw.channels_max = hinfo->channels_max; runtime->hw.formats = hinfo->formats; runtime->hw.rates = hinfo->rates; + runtime->hw.period_bytes_max = 32768; // XXX snd_pcm_limit_hw_rates(runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); This is merely a hackish workaround, but worth to try.
(In reply to Takashi Iwai from comment #219) > Is this with tsched=0? I wonder why PA gets the position information so > often. Without tsched change, PA should access to the hardware much less > frequently. > > In anyway, one another interesting experiment is to reduce the max period > size, something like below on top of the previous patch: > > --- a/sound/pci/hda/hda_controller.c > +++ b/sound/pci/hda/hda_controller.c > @@ -607,6 +607,7 @@ static int azx_pcm_open(struct snd_pcm_substream > *substream) > runtime->hw.channels_max = hinfo->channels_max; > runtime->hw.formats = hinfo->formats; > runtime->hw.rates = hinfo->rates; > + runtime->hw.period_bytes_max = 32768; // XXX > snd_pcm_limit_hw_rates(runtime); > snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); > > This is merely a hackish workaround, but worth to try. No, this is with tsched removed from the parameter, so it should be one. I’m forcing tsched to zero to not have the issue in PA, otherwise the issue is not present. If you like, I can post the same trace with tsched=0, if that will help you narrow down the issue. I’ll try the patch shortly, Thanks again for your time, Marco.
OK, thanks. Then it looks like that it's really the chip that stalls the playback. Around time 8102 until 8106, there is no playback position update and proceed. The same position is kept for 4 seconds by some reason. If this happens only at the full-duplex (capture and playback mixture) trigger time, it might be in the SYNC register operation. In that case, a change like below might influence on the behavior.
Created attachment 284213 [details] Patch to remove stream sync calls
(In reply to Takashi Iwai from comment #221) > OK, thanks. Then it looks like that it's really the chip that stalls the > playback. Around time 8102 until 8106, there is no playback position update > and proceed. The same position is kept for 4 seconds by some reason. > > If this happens only at the full-duplex (capture and playback mixture) > trigger time, it might be in the SYNC register operation. In that case, a > change like below might influence on the behavior. Nothing changed, unfortunately. Same behavior as before :(
OK. And changing the period_bytes_max doesn't have any influence, either?
(In reply to Takashi Iwai from comment #224) > OK. And changing the period_bytes_max doesn't have any influence, either? Whoops, I completely forgot about the previous hack. Unfortunately, nothing changes; same thing, same timing.
Then I have no better idea for now than disabling the tsched on PA. The patch below is a combination of the former patch (modified no.6) and the flag set to enforce tsched=0. This should work without changing PA config. Let me know if this works better. If the things work reasonably enough, I'm going to push it to upstream.
Created attachment 284221 [details] Test fix patch no.7
(In reply to Takashi Iwai from comment #226) > Then I have no better idea for now than disabling the tsched on PA. > > The patch below is a combination of the former patch (modified no.6) and the > flag set to enforce tsched=0. This should work without changing PA config. > > Let me know if this works better. If the things work reasonably enough, I'm > going to push it to upstream. All is working fine here from my side.
completely not working here. also not patch 7. with pa sound is jumping, and with alsa I just get a random noise. does this work for anybody with X399 board alc1220?
(In reply to daxcore from comment #229) > completely not working here. also not patch 7. with pa sound is jumping, and > with alsa I just get a random noise. > > does this work for anybody with X399 board alc1220? That sounds like a different problem. Especially a random noise shouldn't be caused by the DMA position bug. Try to clear the audio setup once. Does the audio work on any other OS at all?
Everything seems good so far, input not crackling, discord ok. ALC1220 on X470.
I notice the following in the log with patch 7: Also, I don't know if it's expected but enabling 'mic boost' produces a lot of noise. pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: We were woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: Most likely this is a bug in the ALSA driver 'snd_hda_intel'. Please report this issue to the ALSA developers. pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: ALSA woke us up to read new data from the device, but there was actually nothing to read.
(In reply to Térence Clastres from comment #232) > I notice the following in the log with patch 7: > Also, I don't know if it's expected but enabling 'mic boost' produces a lot > of noise. > > pulseaudio[3370]: E: [alsa-source-ALC1220 Analog] alsa-source.c: We were > woken up with POLLIN set -- however a subsequent snd_pcm_avail() returned 0 > or another value < min_avail. That's mostly harmless chats from PA unless you hear anything obvious due to this. The noise by the mic boost is also normal. It's rather a codec side problem and the hardware implementation itself.
Patch 7 works very well here too AFAICT. Multiple playback streams and recording at the same time with PA. With patch 2 you didn't have to disable tsched, but perhaps that was a horrible hack in some other way.. ? (And I can go pretty high on mic boost without very much noise).
Basically patch 2 and 7 are essentially doing same wrt the position report. The latter uses the fixed FIFO size instead of reading the register and it reports the actual delay size as well. But the difference is likely irrelevant with PA tsched problem Marco was seeing. I guess PA would work without tsched hack even after removing the BATCH flag hack from the patch7 on your machine. I really have no idea what triggers the problem and how. More experiment results are appreciated. In anyway, I already submitted the patch7 to upstream and merged now. It'll be included in the next pull request to Linus, so likely landed in 5.3-rc4, then backported to stable trees afterward.
Patch 7 does not work on my system with the runtime->hw.info |= SNDRV_PCM_INFO_BATCH; statement removed.
What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1], together with dropping SNDRV_PCM_INFO_BATCH flag? Still getting the same problem?
Tried patch #7 without BATCH flag, this is not working with discord, there is a delay, and the playback stream jump around when pressing button "Let's Check".
(In reply to David from comment #238) > Tried patch #7 without BATCH flag, this is not working with discord, there > is a delay, and the playback stream jump around when pressing button "Let's > Check". Yea, same here on B450/ALC892 with tsched enabled (which AFAIK the batch flag is the same of disabling tsched on the kernel side of things). Other chipsets instead seems to behave differently (if it is the front end and not the backend, the Realtek codec). Very weird.
(In reply to Takashi Iwai from comment #237) > What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1], > together with dropping SNDRV_PCM_INFO_BATCH flag? Still getting the same > problem? I getting the crackling mic input if I do that yes.
(In reply to Takashi Iwai from comment #230) > (In reply to daxcore from comment #229) > > completely not working here. also not patch 7. with pa sound is jumping, > and > > with alsa I just get a random noise. > > > > does this work for anybody with X399 board alc1220? > > That sounds like a different problem. Especially a random noise shouldn't > be caused by the DMA position bug. Try to clear the audio setup once. > > Does the audio work on any other OS at all? In windows 10 the sound works fine. I guess for X399 boards there is another issue. Non of the patches changed anything here. however, thanks!
(In reply to Takashi Iwai from comment #227) > Created attachment 284221 [details] > Test fix patch no.7 completely fixed the audi for me, ALC 892 + MSI B350M Same tests as before, sound playback works fine as long I'm in a discord channel (the patch 6 only fixed the microphone)
(In reply to Ernst Sjöstrand from comment #240) > (In reply to Takashi Iwai from comment #237) > > What if you remove azx_get_delay_from_fifo assignment to get_delay[0/1], > > together with dropping SNDRV_PCM_INFO_BATCH flag? Still getting the same > > problem? > > I getting the crackling mic input if I do that yes. And you didn't get the same crackling mic input with patch no.2? If so, there are still two differences: - The patch2 calculates the delay from the register - The patch2 applies the delay also for the playback But the second point shouldn't influence on the recording quality. Then it's about the first point, and it can be changed like: --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -866,8 +866,8 @@ static unsigned int azx_get_pos_fifo(struct azx *chip, struct azx_dev *azx_dev) if (!runtime) return pos; - runtime->delay = AMD_FIFO_SIZE; - delay = frames_to_bytes(runtime, AMD_FIFO_SIZE); + delay = snd_hdac_stream_readw(azx_stream(azx_dev), SD_FIFOSIZE) + 1; + runtime->delay = bytes_to_frames(runtime, delay); if (azx_dev->insufficient) { if (pos < delay) { delay = pos; FWIW, the second point can be changed even more simply. --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -878,7 +878,7 @@ static unsigned int azx_get_pos_fifo(struct azx *chip, struct azx_dev *azx_dev) } /* correct the DMA position for capture stream */ - if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) { + if (1 /*substream->stream == SNDRV_PCM_STREAM_CAPTURE*/) { if (pos < delay) pos += azx_dev->core.bufsize; pos -= delay; Let us know if any of these (with/without the get_delay disablement) makes improvement.
So with patch 7, but tsched=1 (ie. not the part with |= BATCH included) I get the following: Only test idea 1: crackling 1+2: no crackling but playback skips when start/stop recording 2: no crackling but playback skips when start/stop recording I retested patch 2 and realized I also have that behavior there: no crackling but playback skips when start/stop recording.
I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220. Audio output works fine but input is cracking and distorted. I tried with patch #2 and patch #7 and no luck on my end. If there is any more information I can provide to be helpful please let me know. Here is my alsa-info http://alsa-project.org/db/?f=900284a51fd5498509bd04653f7b3d653fafa21d
(In reply to Ernst Sjöstrand from comment #244) > So with patch 7, but tsched=1 (ie. not the part with |= BATCH included) I > get the following: > > Only test idea 1: crackling > 1+2: no crackling but playback skips when start/stop recording > 2: no crackling but playback skips when start/stop recording > > I retested patch 2 and realized I also have that behavior there: no > crackling but playback skips when start/stop recording. So, if we delay the playback, too, it works, but it suffers from the stall, too. Interesting.
(In reply to al from comment #245) > I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220. Judging from alsa-info.sh output, your device has a different PCI device ID, 1022:1487. Replace the entry and retest.
(In reply to Takashi Iwai from comment #247) > (In reply to al from comment #245) > > I just picked up a new MSI MPG X570 GAMING EDGE WIFI with Realtek ALC1220. > Judging from alsa-info.sh output, your device has a different PCI device ID, > 1022:1487. Replace the entry and retest. Thanks that did it works great now!
(In reply to al from comment #248) > Thanks that did it works great now! OK, I'll add the entry for 1022:1487 in the upstream, too.
(In reply to Takashi Iwai from comment #249) > (In reply to al from comment #248) > > Thanks that did it works great now! > > OK, I'll add the entry for 1022:1487 in the upstream, too. Ok thanks, I tested with discord and load-module module-loopback and it works perfectly. But with steam I tested my voice for the first minute of testing I sound like a demon, and in valve games the mic is still distorted. Any info I can provide?
(In reply to al from comment #250) > (In reply to Takashi Iwai from comment #249) > > (In reply to al from comment #248) > > > Thanks that did it works great now! > > > > OK, I'll add the entry for 1022:1487 in the upstream, too. > > Ok thanks, I tested with discord and load-module module-loopback and it > works perfectly. > > But with steam I tested my voice for the first minute of testing I sound > like a demon, and in valve games the mic is still distorted. > > Any info I can provide? That is unfortunately correct, in Steam Voice Chat the audio is still stuttering like crazy :S
No issues here with Steam Voice Chat with patch 7 on 1022:1457.
(In reply to Marco from comment #251) > (In reply to al from comment #250) > > (In reply to Takashi Iwai from comment #249) > > > (In reply to al from comment #248) > > > > Thanks that did it works great now! > > > > > > OK, I'll add the entry for 1022:1487 in the upstream, too. > > > > Ok thanks, I tested with discord and load-module module-loopback and it > > works perfectly. > > > > But with steam I tested my voice for the first minute of testing I sound > > like a demon, and in valve games the mic is still distorted. > > > > Any info I can provide? > > That is unfortunately correct, in Steam Voice Chat the audio is still > stuttering like crazy :S The stutters remains only for one minute after activating the webrtc stream on Steam, afterwards the audio clears up and, besides a long delay of around 1/2 of a second, the audio is clear.
That's true, Steam Voice Chat has distortions/delays for 1 minute (but totally different than the usual like it was on Discord) Also, my voice has a much lower pitch too, and only for one minute. But I noticed this is happening on Discord too right when I join a channel (or do a voice self test) for 2 seconds.
(In reply to Luca from comment #254) > That's true, Steam Voice Chat has distortions/delays for 1 minute (but > totally different than the usual like it was on Discord) > Also, my voice has a much lower pitch too, and only for one minute. > > But I noticed this is happening on Discord too right when I join a channel > (or do a voice self test) for 2 seconds. Not for me, on discord the audio is perfect. I still don't get where the problem lies here.
I have MSI A320m mobo with a Realtek ALC887 and got the same problem not sure if others are having another problem with this chip but if i connect a speakers to the rear panel and a headset to the front panel it only detects my front panel it even says "unplugged" in audio settings i have to unplug the headset to get audio from the speakers no hardware problems since it works just fine on Windows 10
(In reply to Khaled from comment #256) > I have MSI A320m mobo with a Realtek ALC887 and got the same problem not > sure if others are having another problem with this chip but if i connect a > speakers to the rear panel and a headset to the front panel it only detects > my front panel it even says "unplugged" in audio settings i have to unplug > the headset to get audio from the speakers no hardware problems since it > works just fine on Windows 10 This is not related to crackled sound capture.
(In reply to Ernst Sjöstrand from comment #257) > (In reply to Khaled from comment #256) > > I have MSI A320m mobo with a Realtek ALC887 and got the same problem not > > sure if others are having another problem with this chip but if i connect a > > speakers to the rear panel and a headset to the front panel it only detects > > my front panel it even says "unplugged" in audio settings i have to unplug > > the headset to get audio from the speakers no hardware problems since it > > works just fine on Windows 10 > > This is not related to crackled sound capture. I know it's not but just wanted to mention it since i can't find a bug report about it plus i am sure the same people that are affected by crackled sound capture are affected by this one as well
(In reply to Khaled from comment #256) > I have MSI A320m mobo with a Realtek ALC887 and got the same problem not > sure if others are having another problem with this chip but if i connect a > speakers to the rear panel and a headset to the front panel it only detects > my front panel it even says "unplugged" in audio settings i have to unplug > the headset to get audio from the speakers no hardware problems since it > works just fine on Windows 10 Before filling a bug in the kernel bugzilla you should check if that happens with Alsa only
Asus A88X-Pro (Realtek 1150) I join the problem in Discord
Distortion/crackled sound in steam voice chat started with kernel 5.2.9. Differently distorted sound in discord web - parts of voice is chopped off every half second or so, and a large lag - 1 second or so. Everything works fine in 5.2.8. Board: ASUS PRIME X370-PRO. lspci -nn extract: 0c:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) HD Audio Controller [1022:1457] Is there a way to disable this patch - with a bootparam perhaps?
(In reply to Vinay Shastry from comment #261) > Everything works fine in 5.2.8. Actually, scratch that. I never tried the mic port until today (didn't have a mic). The crackling is present as reported by others. In 5.2.9, there is a different kind of distortion when using a usb webcam's mic for input + onboard sound card for output on steam voice chat. This new distortion issue wasn't present in 5.2.8 with webcam mic.
(In reply to Vinay Shastry from comment #261) > Distortion/crackled sound in steam voice chat started with kernel 5.2.9. > Differently distorted sound in discord web - parts of voice is chopped off > every half second or so, and a large lag - 1 second or so. > > Everything works fine in 5.2.8. > > > Board: ASUS PRIME X370-PRO. > lspci -nn extract: > 0c:00.3 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Family 17h > (Models 00h-0fh) HD Audio Controller [1022:1457] > > > Is there a way to disable this patch - with a bootparam perhaps? So sounds like I am back in business, I never tried a kernel version lower than 5.3.
Just chiming in: I applied the upstream patch[1] with success on my older-kernel system. It fixed the audio crackle issue on my line-in — thanks Takashi Iwai (: Mobo: ASus X570 Phantom Gaming 4 Audio chipset: ALC1200 (1022:1457) Kernel: 4.19.0 OS: Debian 10 [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/patch/?id=af9d64f871cfe441508f116f31b49410453f96db
(In reply to Takashi Iwai from comment #249) > (In reply to al from comment #248) > > Thanks that did it works great now! > > OK, I'll add the entry for 1022:1487 in the upstream, too. I can't find this entry in the commit. Did you forget or added it in another one?
ASRock Fatal1ty B450 Gaming K4 ALC892, [1022:1457] subsys [1849:9893] With patch no.7 with kernel 4.19.66 and telegram-desktop-bin-1.8.2 my companion hear myself. With patch No. 5 there is no such problem and no crackling.
So you can have different $THING ALC1220 vs ALC892 but still the same pciid 1022:1457 ...
(In reply to Ernst Sjöstrand from comment #267) > So you can have different $THING ALC1220 vs ALC892 but still the same pciid > 1022:1457 ... But the driver is the same one used.
For all people who still see the problem: please test 5.3-rc6 or rc7 kernel and confirm that the problem persists. Once after confirming the same issue with 5.3-rc7, and it's about the PCI device 1022:1457 or 1022:1487, then check the following: 1. Change the return value of azx_get_delay_from_fifo() to 0, e.g. --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -887,7 +887,7 @@ static int azx_get_delay_from_fifo(struct azx *chip, struct azx_dev *azx_dev, struct snd_pcm_substream *substream = azx_dev->core.substream; /* just read back the calculated value in the above */ - return substream->runtime->delay; + return 0; // return substream->runtime->delay; } static unsigned int azx_skl_get_dpib_pos(struct azx *chip, 2. Change the return value of azx_get_delay_from_fifo() to 0 only for playback, e.g. --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -887,7 +887,9 @@ static int azx_get_delay_from_fifo(struct azx *chip, struct azx_dev *azx_dev, struct snd_pcm_substream *substream = azx_dev->core.substream; /* just read back the calculated value in the above */ - return substream->runtime->delay; + if (substream->stream == SNDRV_PCM_STREAM_CAPTURE) + return substream->runtime->delay; + return 0; } static unsigned int azx_skl_get_dpib_pos(struct azx *chip, 3. Drop SNDRV_PCM_INFO_BATCH workaround in hda_controller.c --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -613,12 +613,14 @@ static int azx_pcm_open(struct snd_pcm_substream *substream) 20, 178000000); +#if 0 /* by some reason, the playback stream stalls on PulseAudio with * tsched=1 when a capture stream triggers. Until we figure out the * real cause, disable tsched mode by telling the PCM info flag. */ if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) runtime->hw.info |= SNDRV_PCM_INFO_BATCH; +#endif if (chip->align_buffer_size) /* constrain buffer sizes to be multiple of 128
(In reply to Takashi Iwai from comment #269) > For all people who still see the problem: please test 5.3-rc6 or rc7 kernel > and confirm that the problem persists. Tried with 5.3-rc6 Problem: Distorted sound with steam voice chat with 1022:1457. > 1. Change the return value of azx_get_delay_from_fifo() to 0, e.g. Didn't help. > 2. Change the return value of azx_get_delay_from_fifo() to 0 only for > playback, e.g. Didn't help. > 3. Drop SNDRV_PCM_INFO_BATCH workaround in hda_controller.c This fixed it! Normal sound on steam voice chat (also ok on skype, discord web) - with front mic jack as well as usb webcam.
OK, that's good to know. And how is the application set up? Does it run over PulseAudio backend or accesses directly ALSA devices? The BATCH workaround was needed for PulseAudio. Does any other application using PulseAudio (wrt capture) work on your device? And it'd be strange if this setup change makes any difference on USB webcam behavior. If so, it must be a bug in PulseAudio.
(In reply to Takashi Iwai from comment #271) > And how is the application set up? Does it run over PulseAudio backend or > accesses directly ALSA devices? Everything on PulseAudio. (Using a standard gnome desktop.) > The BATCH workaround was needed for PulseAudio. Does any other application > using PulseAudio (wrt capture) work on your device? Well, I've also tried arecord, gnome-sound-recorder. These and Skype work with and without the BATCH workaround. Steam and Discord have severe issues with the workaround. > And it'd be strange if this setup change makes any difference on USB webcam > behavior. If so, it must be a bug in PulseAudio. The patch seems to trigger the issue as long as the device is in use - even if just for playback. With the workaround, if I use HDMI output and USB webcam, the sound is OK (i.e, this device not in use). Sound card's line-out + any input source causes problem.
Hmm, would it be only about playback? That is, restricting the workaround only to capture stream works better? --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -617,7 +617,8 @@ static int azx_pcm_open(struct snd_pcm_substream *substream) * tsched=1 when a capture stream triggers. Until we figure out the * real cause, disable tsched mode by telling the PCM info flag. */ - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) + if ((chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) && + substream->stream == SNDRV_PCM_STREAM_CAPTURE) runtime->hw.info |= SNDRV_PCM_INFO_BATCH; if (chip->align_buffer_size) In anyway, we need to know this change makes sense at all. IOW, people need to check whether this causes yet another regression on the devices that have worked with BATCH workaround.
(In reply to Takashi Iwai from comment #269) > For all people who still see the problem: please test 5.3-rc6 or rc7 kernel > and confirm that the problem persists. Tried with 5.3-rc6 Problem: Distorted sound with steam voice chat with 1022:1487. # 3 Worked for steam voice chat but unfortunately not in game eg. Counter-Strike: Global Offensive Discord is mic is now distorted unless I set tsched=0 but if I set that then Steam chat is distorted. I will check the above patch shortly
(In reply to Takashi Iwai from comment #273) > Hmm, would it be only about playback? That is, restricting the workaround > only to capture stream works better? > > --- a/sound/pci/hda/hda_controller.c > +++ b/sound/pci/hda/hda_controller.c > @@ -617,7 +617,8 @@ static int azx_pcm_open(struct snd_pcm_substream > *substream) > * tsched=1 when a capture stream triggers. Until we figure out the > * real cause, disable tsched mode by telling the PCM info flag. > */ > - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) > + if ((chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) && > + substream->stream == SNDRV_PCM_STREAM_CAPTURE) > runtime->hw.info |= SNDRV_PCM_INFO_BATCH; > > if (chip->align_buffer_size) > > > In anyway, we need to know this change makes sense at all. IOW, people need > to check whether this causes yet another regression on the devices that have > worked with BATCH workaround. With the standard flags, Discord is perfect, Steam has stutters for the first minute and a bit of delay (500 ms). With the batch flag only on the capture stream, Steam is perfect, Discord has delayed audio. With the batch flag only on the playback stream, same thing with both of them (first case).
Following my previous post, disabling the batch flag on both streams (patch 3 from comment 269), Steam is perfect, Discord is lagged again while acquiring. With the second patch from the comment 269, same identical problem without the patch (Discord perfect, Steam crackling for the first minute + audio slightly delayed). However when changing volume there was a little bit of distortion on the output audio (extremely small, but still audible, especially on high volumes), but it seems that using the workaround only on acquisition seems to have removed that small issue. If someone here had the same problem when changing volume, please try patch n.2 and report back. It seems that we can't have both working together simultaneously on my end. The default workaround is still the best option on my system, for now.
in the final release of Linux 5.3 are going to be these patches? I ask because I am buying an amd laptop right now with ryzen 5 3550 H and want to know how was going this problem ! In an acer swift with AMD ryzen I had the problem
(In reply to Takashi Iwai from comment #271) (In reply to Takashi Iwai from comment #249) > (In reply to al from comment #248) > > Thanks that did it works great now! > > OK, I'll add the entry for 1022:1487 in the upstream, too. The patch was backported to the 4.19.67 kernel. With this and latest Gentoo stable kernel 4.19.72 and net-im/telegram-desktop-bin-1.8.8 my companion hear myself while audio call. No echo cancellation. ASRock Fatal1ty B450 Gaming K4 ALC892, [1022:1457] subsys [1849:9893]
This patch, as applied to the latest 5.3 kernel, is not working on my SO's desktop machine, running Arch Linux, still glitching in Discord voice chat. Gigabyte Aorus B450 Pro Wi-Fi ALC1220, [1022:15e3] subsys [1458:a0c3] alsainfo, if useful: http://alsa-project.org/db/?f=105ba36f537312d1119e5f9ea5810a86ac4db68d
Yours has a different controller chip, so the patch doesn't have any effect as is. Try a freshly submitted / merged patch on top of the previous fixes: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=d2c63b7dfd06788a466d5ec8a850491f084c5fc2
(In reply to Takashi Iwai from comment #280) > Yours has a different controller chip, so the patch doesn't have any effect > as is. > > Try a freshly submitted / merged patch on top of the previous fixes: > > https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/ > ?id=d2c63b7dfd06788a466d5ec8a850491f084c5fc2 Will this patch be in the future stable Linux releases ? I mean if Linux 5.3.1 will have this patch by default. It is curiosity because I don't know how Linux versions works
(In reply to Marco from comment #276) > Following my previous post, disabling the batch flag on both streams (patch > 3 from comment 269), Steam is perfect, Discord is lagged again while > acquiring. > > With the second patch from the comment 269, same identical problem without > the patch (Discord perfect, Steam crackling for the first minute + audio > slightly delayed). However when changing volume there was a little bit of > distortion on the output audio (extremely small, but still audible, > especially on high volumes), but it seems that using the workaround only on > acquisition seems to have removed that small issue. If someone here had the > same problem when changing volume, please try patch n.2 and report back. > > It seems that we can't have both working together simultaneously on my end. > The default workaround is still the best option on my system, for now. The second patch cited in my previous post is necessary now (under 5.3.5, not sure about the previous kernel versions); besides the small crackles when changing volumes, the acquisition from the microphone under load (compilation, for example) sometimes becomes extremely low quality (like if the sample rate is changing randomly and often the audio is clipping). Applying the patch only on the capture stream completely fix the issue, no crackles when changing volume and no issue when acquiring audio with Discord under load. Steam still shows random audio stutters while acquiring for a minute and a bit of delay, so that is still unchanged, unfortunately.
Confirming this for ALC887-VD Analog [ALC887-VD Analog] Audio device [0403]: Advanced Micro Devices, Inc. [AMD] FCH Azalia Controller [1022:780d] (rev 01) Crackling seems to only go away when mix is set to lower than 10% in pulseaudio. If the device oversaturates it seems to try to lower the volume and starts to crackle for a while making it unusable to record or talk for a long time. This has been around for a long time now. It seems there is already a patch but im kinda worried by the version number. 5.3.x seems pretty far away from stable releases(5.0.0-27-generic)?
Why the issue is back? i remember in Linux kernel 5.3 RC7 it was fixed but now it's back my audio codec is ALC887-VD
The problem still seems to affect Raven Ridge ([1022:15e3] in a HP ProBook 455R G6) using kernel version 5.6.4. Disabling the SNDRV_PCM_INFO_BATCH workaround subjectively improves capture quality using `parecord` but it is not really usable either way.
Updates on this long endeavor as of today: I choose to give another try for switching from PulseAudio to the PipeWire sound server. The problems are completely gone. No audio clicking anywhere on the system. I have tried one month ago, but on reboot I was not having any audio coming out from the system. Now everything worked on install right from the get go. Tried also the mic under Steam, which always had audio clicking issue while acquiring and audio stalling (don't remember under what condition); acquisition is now perfect. Tried to dual test recording from Steam Voice and Discord while playing audio, no delay, no crackling, no issue. All streams are working simultaneously. I still have not long tested this, by the way, but on a first impression, yes, it fixed a lot of issues for me. The only minor configuration issue was to switch the microphone detection method in the PipeWire configuration file, otherwise no microphone were detected. After that, everything work as it should, for now. The issue on my end was definitely PulseAudio. If you still have problems, try PipeWire if you can or if fits your needs. This definitely solved my problems, maybe it will help yours too. Marco.
FYI, the 'solution' for this issue that is now in the kernel breaks capturing screen+currrently playing audio with ffmpeg, for me at least, on AMD Raven hardware. I tried many things but could not achieve good audio capture that is synchronised, not when capturing from Pulse anyway. I'm guessing it's being in BATCH mode, and Pulse not operating with tsched, that is the problem, not the rest of the patchwork. Nonetheless I just wanted things to work as before without any doubt, so I now have my kernel patched with the following (restoring 1022:15e3 to use the parameter sets it used to before all this) and everything is working fine now: diff -Naur a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c --- a/sound/pci/hda/hda_intel.c 2021-02-10 19:29:23.000000000 +1100 +++ b/sound/pci/hda/hda_intel.c 2021-02-14 02:42:38.714796278 +1100 @@ -2601,7 +2601,8 @@ AZX_DCAPS_PM_RUNTIME }, /* AMD Raven */ { PCI_DEVICE(0x1022, 0x15e3), - .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_AMD_SB }, + .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_SB | + AZX_DCAPS_PM_RUNTIME }, /* ATI HDMI */ { PCI_DEVICE(0x1002, 0x0002), .driver_data = AZX_DRIVER_ATIHDMI_NS | AZX_DCAPS_PRESET_ATI_HDMI_NS }, -- While I greatly appreciate the work on the microphone input crackling issue (which I have experienced and been annoyed by myself over the years), i'm concerned that the current solution should've been further tested and developed before being mainlined.
That's a good discovery. This change makes sense, as the different of PRESET_ATI_SB from PRESET_AMD_SB is about the position reporting. ATI_SB uses the legacy LPIB register read while AMD_SB uses the position buffer table. This could be verified by changing position_fix module option: 1 is LPIB and 2 is position buffer. If we can confirm that this change generally improves the behavior, I can merge the fix quickly to the upstream. Can anyone else check it?
... and looking back at the development history again, this seems too early to be delighted. Actually the change to PRESET_AMD_SB was done as a fix for the certain devices in the commit d2c63b7dfd06788a466d5ec8a850491f084c5fc2 ALSA: hda - Apply AMD controller workaround for Raven platform So moving it back would break something else, too. Hmm. That said, the behavior might depend on the PCM parameters, or the chip revision, BIOS, or whatever subtle things...
Again a correction: the current default setup for Raven corresponds to position_fix=6 option. It's not a simple LPIB read but contains some awkward correction that takes the FIFO size into account.
@Takashi Iwai > So moving it back would break something else, too. Hmm. Indeed, it will break whatever solutions to the original issue of microphone input crackling your changes may have fixed for this sound device. My use case - capturing from the global output monitor - has never had a crackling issue, but is completely broken by the changes. It's a difficult situation.
I should clarify: My broken use case is capturing from the global output monitor while also capturing the screen, and having the audio be synchronised like at capture time. In some of my early tests the audio was not only un-synchronised, but had other issues too (jolting, etc.), so it's possible even just capturing from the audio monitor alone has issues, but i haven't confirmed that.
(In reply to Rob McCathie from comment #292) > I should clarify: My broken use case is capturing from the global output > monitor while also capturing the screen, and having the audio be > synchronised like at capture time. > > In some of my early tests the audio was not only un-synchronised, but had > other issues too (jolting, etc.), so it's possible even just capturing from > the audio monitor alone has issues, but i haven't confirmed that. I have tested this (if i have done it correctly, taken from https://trac.ffmpeg.org/wiki/Capture/Desktop for pulse acquisition, using PipeWire), and besides a small audio missing at the start of the recording of about one second and at the end of it (but that was maybe caused to the ctrl-c to ffmpeg, I'm not sure about that), it looks pretty much synchronized to me, using a microphone next to my mouse and selecting text on the screen I can't really see any delay on it (on the current implemented workaround, Kernel 5.11) Mind you, I'm on a 0x1487 and not on a 0x15e3 host side controller (not an "AMD Raven"), so maybe the behavior of the two controllers are different from each other (or PipeWire is not causing the issue here). Marco.
1487 is with the same setup as Raven (15e3), and the same workaround is applied. Please note that the workaround isn't actually delaying the sound transfer. Instead, it reports the PCM delay value up to 32bytes for FIFO size for the applications. If the application (the sound backend) doesn't take the delay attribute into account, it's of course unaffected. I don't know whether PipeWire behaves properly for the delay evaluation, though.
Indeed. My issue relates to usage with Pulse. PipeWire looks like an interesting up-and-coming project, but right now Pulse is what is rolled out in the vast majority of distros and, for now, tales of outcomes with PipeWire aren't so useful.
Just thought i'd update on my situation, i've now tested that it is only the Pulse changing to batch mode that causes my issue. So i'm no longer running the patch i posted earlier, rather now i do this: diff -Naur a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c --- a/sound/pci/hda/hda_controller.c 2021-02-10 19:29:23.000000000 +1100 +++ b/sound/pci/hda/hda_controller.c 2021-02-14 00:38:36.602466066 +1100 @@ -609,13 +609,6 @@ 20, 178000000); - /* by some reason, the playback stream stalls on PulseAudio with - * tsched=1 when a capture stream triggers. Until we figure out the - * real cause, disable tsched mode by telling the PCM info flag. - */ - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) - runtime->hw.info |= SNDRV_PCM_INFO_BATCH; - if (chip->align_buffer_size) /* constrain buffer sizes to be multiple of 128 bytes. This is more efficient in terms of memory ------------------ It's my opinion that the above reversion should be done in mainline. A bugfix that fixes a problem over here but creates a new one over there isn't a bugfix at all.
(In reply to Rob McCathie from comment #296) > Just thought i'd update on my situation, i've now tested that it is only the > Pulse changing to batch mode that causes my issue. So i'm no longer running > the patch i posted earlier, rather now i do this: > > > > diff -Naur a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c > --- a/sound/pci/hda/hda_controller.c 2021-02-10 19:29:23.000000000 +1100 > +++ b/sound/pci/hda/hda_controller.c 2021-02-14 00:38:36.602466066 +1100 > @@ -609,13 +609,6 @@ > 20, > 178000000); > > - /* by some reason, the playback stream stalls on PulseAudio with > - * tsched=1 when a capture stream triggers. Until we figure out the > - * real cause, disable tsched mode by telling the PCM info flag. > - */ > - if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) > - runtime->hw.info |= SNDRV_PCM_INFO_BATCH; > - > if (chip->align_buffer_size) > /* constrain buffer sizes to be multiple of 128 > bytes. This is more efficient in terms of memory > > > > ------------------ > > It's my opinion that the above reversion should be done in mainline. A > bugfix that fixes a problem over here but creates a new one over there isn't > a bugfix at all. FWIW, on my system this improves the recording start, removing completely audio clicks at the start of recording (no audio stalls in reproduction, even with multiple streams on acquisition while playing audio), so for my use case it's fine, but someone with PulseAudio should test this and see if it causes regressions.
Yes, that's merely an ugly workaround, and I'd happily get rid of it once after confirming it's working fine without that!
OK, I'm going to submit this partial revert.
Created attachment 295735 [details] The partial revert patch
I hit this issue as well on my Gentoo box (see https://bugs.gentoo.org/779157). After applying the patch mentioned in comment #296, the audio is back to normal with PulseAudio, no more distortions, the audio is clean. No perceived audio lags. Everything is in working order again. Tested only with 5.10.24 and 5.10.26 here, will test with a 5.11.x kernel later.
Any update on this? Perhaps I have a misunderstanding, however the issue is still here unless I do a patch -R with what is in comment #296. Even with the latest 5.11.13...
Update after the latest firmware update for the platform, called AMD AGESA V2 PI 1.2.0.3 Patch A, released yesterday for my platform, finally. This includes the USB patch for the drop in the USB communication under load for too much recovery errors hitting the Pci-Ex subsystem on the chipset, apparently, that was only present when using Pci-Ex 4 (B5xx and X5xx, not on b4xx, in theory). However, the USB issues was still present even on older platform, apparently. Just not as grave as the 500 series. The audio clicking is completely gone and the machine is finally much more responsive; I've yet have to test the system under high loads, but even on the desktop the audio clicking was audible sometimes, when event from application fires; after the firmware update, this is completely disappeared. The audio now is perfect, at least in output. I'll update here as soon as I can test the recording now. I didn't think it would change much. But, for me at least, it did.
After some gaming and streaming, I can confirm that I haven't heard anymore pops or clicks, and a lot of performance issues completely disappeared after applying this firmware, like microstutters in the system under load and such. Kinda makes sense, since PciEx is basically the main bus where everything is connected on a modern PC; I guess better late than never. I'll keep monitored the situation, but I think that at least for me after this firmware update the issue has been finally fixed.
(In reply to Frédéric Pierret from comment #5) > Hi, > > I also had the same problem with my ASROCK X370 Gaming K4 (ALC1220): > > 1st case: Booting FIRST Linux: Sound with noise/crackling. > 2nd case: Booting FIRST Windows and SECOND Linux: Sound is perfect. > > I suceed in solving the problem by comparing the Coeff values in both cases > and assign the values of the second case in a script at boot time. How to: > > - Install alsa-tools. > - In both cases, you have to: echo 1 > > /sys/module/snd_hda_codec/parameters/dump_coefs > - Then, in the first case, alsa-info --no-upload --output infos_bad > - Then, in the second case, alsa-info --no-upload --output infos_good > - Finally, you compare the coef values: diff infos_bad infos_good | grep > Coeff > > For changing the value of each different Coeff, you need to proceed as > follow: for example, changing Coeff 0x67 to value 0x3000 > > hda-verb /dev/snd/hwC0D0 0x20 SET_COEF_INDEX 0x67 > hda-verb /dev/snd/hwC0D0 0x20 SET_PROC_COEF 0x3000 > > You have to do this in the growing order of Coeff. Remark that hwC0D0 refers > to your sound card. In case of HDMI output like me, my sound card if hwC1D0. > > Here is a quick script: > > ------------------------------------------------------------------------ > #!/bin/bash > > coeffs=($(echo 0x{16,43,44,5d,5e,63,67})) > values=($(echo 0x{8020,3405,fa10,0606,0000,e430,3000})) > > for i in `seq 0 $(( ${#coeffs[@]} - 1 ))` > do > hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX ${coeffs[$i]} && hda-verb > /dev/snd/hwC1D0 0x20 SET_PROC_COEF ${values[$i]} > done > ------------------------------------------------------------------------ > > Just change the coeffs to change in the array 'coeffs' and the new values in > array 'values' and exec this script. A remark, while I do not shutdown the > power supply, my audio chipset keeps the values. This is why you need to do > the FIRST case (first...) and then the second. Then, you could test if it > works only when you shutdown the power supply of your mobo and then booting > into Linux directly. > > I'm preparing a patch for the kernel but for those who have the problem, > could you post your coeff/values which need to be change please. > > Hope this helps. Hi Frederic, thank you for sharing your approach and script. It helped me to solve a problem with my ALC3234 (Dell Optiplex 3040 Micro). The analog output format was limited to 44.1kHz/48kHz after direct linux boot. With a previous Windows boot, additional 96kHz/192kHz are available. I will attach the adapted script, that works for me. May be it helps someone.
Created attachment 304321 [details] script to adapt alc3234 codec coefs
Created attachment 304349 [details] patch_realtek_alc1220_record.diff Hi all: Basically, ASUS CROSSHAIR VI HERO only provides Windows version, not Linux version. You can try it, after entering the LINUX OS (ALC1220, 0x10ec1022, subsytem ID: 10438735) "sudo su root" type root password "hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x15" "hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0x06e0" "hda-verb /dev/snd/hwC1D0 0x20 SET_COEF_INDEX 0x6f" "hda-verb /dev/snd/hwC1D0 0x20 SET_PROC_COEF 0xc03b" Try recording, will it still break? If possible, please install the PATCH file in the LINUX Kernel source and try it out. Best regards pshou -----Original Message----- From: bugzilla-daemon@kernel.org <bugzilla-daemon@kernel.org> Sent: Thursday, May 25, 2023 8:13 PM To: Pshou <pshou@realtek.com> Subject: [Bug 195303] AMD HD-audio controller: Sound capture is crackled / distorted External mail. https://bugzilla.kernel.org/show_bug.cgi?id=195303 --- Comment #306 from haro41@gmx.de --- Created attachment 304321 [details] --> https://bugzilla.kernel.org/attachment.cgi?id=304321&action=edit script to adapt alc3234 codec coefs -- You may reply to this email to add a comment. You are receiving this mail because: You are on the CC list for the bug. ------Please consider the environment before printing this e-mail.
For ASUS-specific codec issues, could you open another bug instead of hanging this old issue? The AMD controller problem was basically fixed, and the Realtek codec quirk is a different story.
Done: https://bugzilla.kernel.org/show_bug.cgi?id=217526