With the default pulseaudio (media-sound/pulseaudio-13-r1) settings (i.e. what comes as vanilla settings), everything related to pulseaudio was working like a charm.... at least until gentoo-sources 5.10.24 (I have the issue with 5.11.x kernel series as well). The last "good" kernel was gentoo-sources-5.10.23. Now, I have severe sound distortions. I tried to set "avoid-resampling = yes" in /etc/pulse/daemon.conf. Semi-success, some apps are fixed but others like games-fps/doomsday are unplayable (FX comes delayed by several seconds). I tried to bring in the latest pulseadudio 14.2, no success same issue. Either the sound is distorted either it lags. Audio Codec is a Realtek ALC1220 (HDAudio)
This is just a stab in the dark but if the issue is also present in sys-kernel/vanilla-sources-5.10.24 but not sys-kernel/vanilla-sources-5.10.23, then it may be related to this: https://bugzilla.kernel.org/show_bug.cgi?id=195303 And the associated likely suspect commit: https://patchwork.kernel.org/project/alsa-devel/patch/20210308160726.22930-1-tiwai@suse.de/ Otherwise, just ignore my ramblings. A git bisect would be best, of course.
We saw the same message. Thanks for pointing the kernel.org bug. I am narrowing down the patchset 5.10.23->5.10.24.
Applied this patchset (i.e. evrything related to sound): +++ b/sound/core/init.c +++ b/sound/core/memalloc.c +++ b/sound/core/oss/pcm_oss.c +++ b/sound/core/pcm.c +++ b/sound/core/pcm_local.h +++ b/sound/core/pcm_native.c +++ b/sound/core/rawmidi.c +++ b/sound/core/seq/oss/seq_oss_synth.c +++ b/sound/core/seq/seq_queue.h +++ b/sound/firewire/fireface/ff-protocol-latter.c +++ b/sound/firewire/fireface/ff-transaction.c +++ b/sound/firewire/tascam/tascam-transaction.c +++ b/sound/hda/intel-dsp-config.c +++ b/sound/hda/intel-nhlt.c +++ b/sound/pci/ctxfi/cthw20k2.c +++ b/sound/pci/hda/hda_bind.c +++ b/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_sysfs.c +++ b/sound/pci/hda/hda_tegra.c +++ b/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_conexant.c +++ b/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_via.c +++ b/sound/soc/amd/acp-da7219-max98357a.c +++ b/sound/soc/amd/raven/pci-acp3x.c +++ b/sound/soc/amd/renoir/rn-pci-acp3x.c +++ b/sound/soc/atmel/Kconfig +++ b/sound/soc/codecs/ak4458.c +++ b/sound/soc/codecs/cpcap.c +++ b/sound/soc/codecs/cros_ec_codec.c +++ b/sound/soc/codecs/cs42l56.c +++ b/sound/soc/codecs/cx2072x.c +++ b/sound/soc/codecs/max98390.c +++ b/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt711.c +++ b/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8997.c +++ b/sound/soc/codecs/wm8998.c +++ b/sound/soc/codecs/wm_adsp.c +++ b/sound/soc/codecs/wsa881x.c +++ b/sound/soc/generic/simple-card-utils.c +++ b/sound/soc/intel/Kconfig +++ b/sound/soc/intel/boards/bytcr_rt5640.c +++ b/sound/soc/intel/boards/bytcr_rt5651.c +++ b/sound/soc/intel/boards/haswell.c +++ b/sound/soc/intel/boards/sof_maxim_common.c +++ b/sound/soc/intel/boards/sof_sdw.c +++ b/sound/soc/intel/common/soc-intel-quirks.h +++ b/sound/soc/intel/skylake/cnl-sst.c +++ b/sound/soc/intel/skylake/skl-topology.c +++ b/sound/soc/jz4740/jz4740-i2s.c +++ b/sound/soc/mediatek/mt8183/mt8183-da7219-max98357.c +++ b/sound/soc/mediatek/mt8183/mt8183-mt6358-ts3a227-max98357.c +++ b/sound/soc/meson/Kconfig +++ b/sound/soc/meson/axg-tdm-interface.c +++ b/sound/soc/meson/axg-tdmin.c +++ b/sound/soc/qcom/Kconfig +++ b/sound/soc/qcom/common.c +++ b/sound/soc/qcom/lpass-apq8016.c +++ b/sound/soc/qcom/lpass-cpu.c +++ b/sound/soc/qcom/lpass-hdmi.c +++ b/sound/soc/qcom/lpass-ipq806x.c +++ b/sound/soc/qcom/lpass-lpaif-reg.h +++ b/sound/soc/qcom/lpass-platform.c +++ b/sound/soc/qcom/lpass-sc7180.c +++ b/sound/soc/qcom/lpass.h +++ b/sound/soc/qcom/qdsp6/q6afe-clocks.c +++ b/sound/soc/qcom/qdsp6/q6asm-dai.c +++ b/sound/soc/qcom/qdsp6/q6routing.c +++ b/sound/soc/sh/siu.h +++ b/sound/soc/sh/siu_pcm.c +++ b/sound/soc/soc-dapm.c +++ b/sound/soc/soc-pcm.c +++ b/sound/soc/soc-topology.c +++ b/sound/soc/sof/debug.c +++ b/sound/soc/sof/intel/Kconfig +++ b/sound/soc/sof/intel/hda-codec.c +++ b/sound/soc/sof/intel/hda-dsp.c +++ b/sound/soc/sof/sof-pci-dev.c +++ b/sound/soc/sunxi/sun4i-i2s.c +++ b/sound/usb/card.c +++ b/sound/usb/clock.c +++ b/sound/usb/format.c +++ b/sound/usb/midi.c +++ b/sound/usb/mixer.c +++ b/sound/usb/mixer_maps.c +++ b/sound/usb/mixer_quirks.c +++ b/sound/usb/pcm.c +++ b/sound/usb/quirks.c +++ b/sound/usb/stream.c +++ b/sound/usb/usbaudio.h And my isssue is gone. :)
The exact fix is to apply the patch mentioned in comment #296 of Kernel bug #195303 "AMD HD-audio controller: Sound capture is crackled / distorted" (https://bugzilla.kernel.org/show_bug.cgi?id=195303#c296). For the record, the patch is included in this bug. Tested by myself on 5.10.24 and 5.10.26 (untested on 5.10.25 but it should work as well) => Sound is back to normal with pulseaudio. Untested so far with 5.11 series but I can patch the latest released 5.11 kernel (5.11.10) as a quick test, so I guess it will also fix the issue there. Will do that later.
Created attachment 696123 [details, diff] Restore the AMD HDAudio workaround This patch revert a change introduced in Linux 5.10.24 with regards to a workaround for AMD HDAudio Controllers and should be also valid for Linux 5.11 (at least until 5.11.10 which is the latest available in that serie so far).
I think we can all agree that the source code lines in question are: 612 /* by some reason, the playback stream stalls on PulseAudio with 613 * tsched=1 when a capture stream triggers. Until we figure out the 614 * real cause, disable tsched mode by telling the PCM info flag. 615 */ 616 if (chip->driver_caps & AZX_DCAPS_AMD_WORKAROUND) 617 runtime->hw.info |= SNDRV_PCM_INFO_BATCH; What, at least, I am not able to understand is, are you removing or adding back those lines to fix the issue you're having with 5.10.24 and newer kernels?
You have to reverse-apply the patch (patch -R ....) on 5.10.24 or newer. So the "-" lines are meant to be read "+". The filename is a bit misleading, my apologies.
Perhaps it's just a misunderstanding on my part, but you might want to go back to the kernel upstream and explain that rather than applying the patch to an older kernel, you're reverting it for the 5.10.24 kernel to fix your audio.
BTW, kernel 5.10.27 and 5.11.11 are not fixed for this issue. The solution is discussed at upstream (I put the link here), they need to revert what had been previously committed. Until then, just do "patch -R -p1" with the patch attached to this bug when you install a new Gentoo/vanilla kernel :)
Hi, Is the requested fix to revert this? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/sound/pci/hda/hda_controller.c?id=28e96c1693ec1cdc963807611f8b5ad400431e82
Yes. Once you apply the patch with -R, the function azx_pcm_open should be like this and the sound is back to normal: static int azx_pcm_open(struct snd_pcm_substream *substream) { struct azx_pcm *apcm = snd_pcm_substream_chip(substream); struct hda_pcm_stream *hinfo = to_hda_pcm_stream(substream); struct azx *chip = apcm->chip; struct azx_dev *azx_dev; struct snd_pcm_runtime *runtime = substream->runtime; int err; int buff_step; snd_hda_codec_pcm_get(apcm->info); mutex_lock(&chip->open_mutex); azx_dev = azx_assign_device(chip, substream); trace_azx_pcm_open(chip, azx_dev); if (azx_dev == NULL) { err = -EBUSY; goto unlock; } runtime->private_data = azx_dev; runtime->hw = azx_pcm_hw; if (chip->gts_present) runtime->hw.info |= SNDRV_PCM_INFO_HAS_LINK_SYNCHRONIZED_ATIME; runtime->hw.channels_min = hinfo->channels_min; runtime->hw.channels_max = hinfo->channels_max; runtime->hw.formats = hinfo->formats; runtime->hw.rates = hinfo->rates; snd_pcm_limit_hw_rates(runtime); snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS); /* avoid wrap-around with wall-clock */ snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_BUFFER_TIME, 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;
I have a distorded sound on my: 00:05.0 Audio device: NVIDIA Corporation MCP61 High Definition Audio (rev a2) Subsystem: ASUSTeK Computer Inc. MCP61 High Definition Audio Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22, NUMA node 0 Memory at dbff8000 (32-bit, non-prefetchable) [size=16K] Capabilities: [44] Power Management version 2 Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+ Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+ Kernel driver in use: snd_hda_intel It works fine on 5.4.97. But not on 5.10.27… But it does not look the same. The patch does not work for me. I am trying 5.10.23 tomorrow. I also tried to look at power safe (seems to cause some issue too): https://bbs.archlinux.org/viewtopic.php?id=262246 But I do not have any “power_safe” file in /sys.
Feel free to try 5.10.23 but either way you'll likely need to git bisect between a known good and known bad versions to find the particular culprit for this to get fixed. I did a quick search but, likely because nForce has long fallen out of widespread use, you may very well be the first person to hit this, so it's very much in your hands. You could also try sys-kernel/gentoo-kernel-bin just to rule out an issue with the kernel config. A new bug report would be good either way, because this one is about a higher-end AMD HDA adapter, but it's especially important to file a new bug if 5.10.23 is also broken.
Thanks Niklāvs. After a quick reboot, I can say that I have “my” issue with 5.10.23. So certainly not the same bug. I will try to find out the version by testing old 5.x and take a look at kernel config. There is some new options between 5.4 and 5.10 config files: @@ -2075,7 +2074,6 @@ # CONFIG_SND_HDA=y CONFIG_SND_HDA_INTEL=y -# CONFIG_SND_HDA_INTEL_DETECT_DMIC is not set # CONFIG_SND_HDA_HWDEP is not set # CONFIG_SND_HDA_RECONFIG is not set # CONFIG_SND_HDA_INPUT_BEEP is not set @@ -2092,11 +2090,14 @@ # CONFIG_SND_HDA_CODEC_CMEDIA is not set # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=y +# CONFIG_SND_HDA_INTEL_HDMI_SILENT_STREAM is not set # end of HD-Audio CONFIG_SND_HDA_CORE=y +CONFIG_SND_HDA_COMPONENT=y CONFIG_SND_HDA_PREALLOC_SIZE=2048 CONFIG_SND_INTEL_NHLT=y +CONFIG_SND_INTEL_DSP_CONFIG=y # CONFIG_SND_USB is not set # CONFIG_SND_SOC is not set # CONFIG_SND_X86 is not set Yes, it is a bit old. But it still work fine ;). https://www.kernel.org/category/releases.html 5.4 will be maintained until 2025. Good to know. At that moment this computer will celebrate his 18!
any update?
Issue still present with 5.11.13, very likely to be also present in 5.10.29 and forthcoming 5.11.14 (untested, to be confirmed). No patch of any kind has been integrated with regards to this issue in sys-kernel/gentoo-sources so far. No comment in the upstream bug since march, 30th 2021.
With all due respect, Adrien, I do believe that upstream's understanding is that your issue was **fixed by applying** the commit that you actually **reverted**. As I said, you need to go back to upstream and explain that it actually caused breakage on your previously working system. Until you do that, upstream thinks all is fine and meanwhile Gentoo can not revert it, because that would break audio for other people that reported in the upstream's thread that the change helped them.
Just poked the upstream ;)
(In reply to Niklāvs Koļesņikovs from comment #13) > A new bug report would be good either way, because this one is about a > higher-end AMD HDA adapter, but it's especially important to file a new bug > if 5.10.23 is also broken. I created #783462 Also upstream https://bugzilla.kernel.org/show_bug.cgi?id=212709 Every version seems buggy. At least: linux-5.6.18-gentoo linux-5.7.19-gentoo linux-5.8.18-gentoo linux-5.9.16-gentoo linux-5.10.0-gentoo linux-5.10.23-gentoo linux-5.10.27-gentoo linux-5.11.14 linux-5.12-rc7 But I did not manage to launch kernels (strange kernel panic at startup, maybe something to do with gcc version 10?): linux-5.5.18 linux-5.5.19-gentoo linux-5.6.0
(In reply to Sébastien P. from comment #19) > (In reply to Niklāvs Koļesņikovs from comment #13) > > A new bug report would be good either way, because this one is about a > > higher-end AMD HDA adapter, but it's especially important to file a new bug > > if 5.10.23 is also broken. > > I created #783462 > Also upstream https://bugzilla.kernel.org/show_bug.cgi?id=212709 > > Every version seems buggy. At least: > linux-5.6.18-gentoo > linux-5.7.19-gentoo > linux-5.8.18-gentoo > linux-5.9.16-gentoo > linux-5.10.0-gentoo > linux-5.10.23-gentoo > linux-5.10.27-gentoo > linux-5.11.14 > linux-5.12-rc7 > > But I did not manage to launch kernels (strange kernel panic at startup, > maybe something to do with gcc version 10?): > linux-5.5.18 > linux-5.5.19-gentoo > linux-5.6.0 Sébastien, you mention "Add CONFIG_SND_HDA_CODEC_ANALOG=y solved the issue." Do you actually need =y , =m will not work?
(In reply to Joakim Tjernlund from comment #20) > Sébastien, you mention "Add CONFIG_SND_HDA_CODEC_ANALOG=y solved the issue." > Do you actually need =y , =m will not work? Just declare it as a module (without loaded it) does not work.
