Created attachment 304639 [details] The dmesg output after boot for the 6.5 RC1 mainline kernel I have a Lenovo ThinkPad X1 Yoga Gen 7 running Arch Linux. Linux 6.4 and higher, cause audio distortion. Sometimes, this occurs to the point that nearly nothing is discernible. This carries over to wired headphones. The issue occurs on the entire mainline 6.4.x kernel series and also the 6.4.3 stable and 6.5 RC1 kernel, which are the latest at the time of writing. The issue occurs on both the Arch distributed kernels, and the mainline kernels. Linux kernels 6.3.x are not affected and neither is the 6.1 LTS kernel series which is what I am temporarily using. On Windows 10/11 too, the audio works as it should. This indicates that my hardware is not at fault. Bluetooth audio is not impacted from my testing, either. The distortion doesn't start immediately. It either occurs automatically after a random amount of time, or when I increase/decrease the volume, or when I skip forward/backward to a section. In order to stop the distortion, I have to either increase/decrease the volume until it stops, or skip forward/backward until it stops, or restart Pipewire via systemd, however it starts again due to one of the aforementioned reasons. At the time of this report, I am running Pipewire 0.3.74 and Wireplumber 0.4.14. This also doesn't seem like a Pipewire/Wireplumber issue, since these same versions work fine on the 6.1 LTS kernels without causing any audio distortion. I wrote about this on the Arch Linux forums, too, and seems like at least two other people are facing this issue. Here's the forum post: https://bbs.archlinux.org/viewtopic.php?id=287068 Furthermore, I filed a bug report on the Arch Linux Bug Reporter, where they suggested that the issue is a kernel regression and should be reported upstream, here. Here's the bug report that I filed on the Arch Linux Bug Reporter for anyone interested: https://bugs.archlinux.org/task/79081?project=1&pagenum=10 I have attached the dmesg outputs of the mainline 6.5 RC1 kernel. Here's some audio related hardware information from my device: inxi -A Audio: Device-1: Intel Alder Lake PCH-P High Definition Audio driver: sof-audio-pci-intel-tgl API: ALSA v: k6.5.0-rc1-1-mainline status: kernel-api pactl info Server String: /run/user/1000/pulse/native Library Protocol Version: 35 Server Protocol Version: 35 Is Local: yes Client Index: 138 Tile Size: 65472 User Name: tux Host Name: NSA-Terminal-4 Server Name: PulseAudio (on PipeWire 0.3.74) Server Version: 15.0.0 Default Sample Specification: float32le 2ch 48000Hz Default Channel Map: front-left,front-right Default Sink: alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp__sink Default Source: alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic.HiFi__hw_sofhdadsp_6__source Cookie: f9dc:5e7a I can't figure out why this is happening. Kindly ask for any more information that is necessary. Thank you.
Created attachment 304640 [details] Pactl detailed sound card information
Also, please pardon me if I did something wrong with filing the bug report. This is my first time filing one.
(In reply to Iyer from comment #0) > Created attachment 304639 [details] > The dmesg output after boot for the 6.5 RC1 mainline kernel > > I have a Lenovo ThinkPad X1 Yoga Gen 7 running Arch Linux. Linux 6.4 and > higher, cause audio distortion. Sometimes, this occurs to the point that > nearly nothing is discernible. This carries over to wired headphones. The > issue occurs on the entire mainline 6.4.x kernel series and also the 6.4.3 > stable and 6.5 RC1 kernel, which are the latest at the time of writing. The > issue occurs on both the Arch distributed kernels, and the mainline kernels. > > Linux kernels 6.3.x are not affected and neither is the 6.1 LTS kernel > series which is what I am temporarily using. On Windows 10/11 too, the audio > works as it should. This indicates that my hardware is not at fault. > Bluetooth audio is not impacted from my testing, either. > > The distortion doesn't start immediately. It either occurs automatically > after a random amount of time, or when I increase/decrease the volume, or > when I skip forward/backward to a section. In order to stop the distortion, > I have to either increase/decrease the volume until it stops, or skip > forward/backward until it stops, or restart Pipewire via systemd, however it > starts again due to one of the aforementioned reasons. > > At the time of this report, I am running Pipewire 0.3.74 and Wireplumber > 0.4.14. This also doesn't seem like a Pipewire/Wireplumber issue, since > these same versions work fine on the 6.1 LTS kernels without causing any > audio distortion. > > I wrote about this on the Arch Linux forums, too, and seems like at least > two other people are facing this issue. Here's the forum post: > https://bbs.archlinux.org/viewtopic.php?id=287068 > > Furthermore, I filed a bug report on the Arch Linux Bug Reporter, where they > suggested that the issue is a kernel regression and should be reported > upstream, here. Here's the bug report that I filed on the Arch Linux Bug > Reporter for anyone interested: > https://bugs.archlinux.org/task/79081?project=1&pagenum=10 > > I have attached the dmesg outputs of the mainline 6.5 RC1 kernel. > > Here's some audio related hardware information from my device: > > inxi -A > > Audio: > Device-1: Intel Alder Lake PCH-P High Definition Audio > driver: sof-audio-pci-intel-tgl > API: ALSA v: k6.5.0-rc1-1-mainline status: kernel-api > > > pactl info > > Server String: /run/user/1000/pulse/native > Library Protocol Version: 35 > Server Protocol Version: 35 > Is Local: yes > Client Index: 138 > Tile Size: 65472 > User Name: tux > Host Name: NSA-Terminal-4 > Server Name: PulseAudio (on PipeWire 0.3.74) > Server Version: 15.0.0 > Default Sample Specification: float32le 2ch 48000Hz > Default Channel Map: front-left,front-right > Default Sink: > alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic. > HiFi__hw_sofhdadsp__sink > Default Source: > alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic. > HiFi__hw_sofhdadsp_6__source > Cookie: f9dc:5e7a > > > I can't figure out why this is happening. Kindly ask for any more > information that is necessary. Thank you. Can you perform bisection between v6.3 and v6.4 to find the culprit (see Documentation/admin-guide/bug-bisect.html for instructions).
Sure, but it might take some time since this is the first time I will be doing so. Kindly bear with me. Thank you.
(In reply to Bagas Sanjaya from comment #3) > (In reply to Iyer from comment #0) > > Created attachment 304639 [details] > > The dmesg output after boot for the 6.5 RC1 mainline kernel > > > > I have a Lenovo ThinkPad X1 Yoga Gen 7 running Arch Linux. Linux 6.4 and > > higher, cause audio distortion. Sometimes, this occurs to the point that > > nearly nothing is discernible. This carries over to wired headphones. The > > issue occurs on the entire mainline 6.4.x kernel series and also the 6.4.3 > > stable and 6.5 RC1 kernel, which are the latest at the time of writing. The > > issue occurs on both the Arch distributed kernels, and the mainline > kernels. > > > > Linux kernels 6.3.x are not affected and neither is the 6.1 LTS kernel > > series which is what I am temporarily using. On Windows 10/11 too, the > audio > > works as it should. This indicates that my hardware is not at fault. > > Bluetooth audio is not impacted from my testing, either. > > > > The distortion doesn't start immediately. It either occurs automatically > > after a random amount of time, or when I increase/decrease the volume, or > > when I skip forward/backward to a section. In order to stop the distortion, > > I have to either increase/decrease the volume until it stops, or skip > > forward/backward until it stops, or restart Pipewire via systemd, however > it > > starts again due to one of the aforementioned reasons. > > > > At the time of this report, I am running Pipewire 0.3.74 and Wireplumber > > 0.4.14. This also doesn't seem like a Pipewire/Wireplumber issue, since > > these same versions work fine on the 6.1 LTS kernels without causing any > > audio distortion. > > > > I wrote about this on the Arch Linux forums, too, and seems like at least > > two other people are facing this issue. Here's the forum post: > > https://bbs.archlinux.org/viewtopic.php?id=287068 > > > > Furthermore, I filed a bug report on the Arch Linux Bug Reporter, where > they > > suggested that the issue is a kernel regression and should be reported > > upstream, here. Here's the bug report that I filed on the Arch Linux Bug > > Reporter for anyone interested: > > https://bugs.archlinux.org/task/79081?project=1&pagenum=10 > > > > I have attached the dmesg outputs of the mainline 6.5 RC1 kernel. > > > > Here's some audio related hardware information from my device: > > > > inxi -A > > > > Audio: > > Device-1: Intel Alder Lake PCH-P High Definition Audio > > driver: sof-audio-pci-intel-tgl > > API: ALSA v: k6.5.0-rc1-1-mainline status: kernel-api > > > > > > pactl info > > > > Server String: /run/user/1000/pulse/native > > Library Protocol Version: 35 > > Server Protocol Version: 35 > > Is Local: yes > > Client Index: 138 > > Tile Size: 65472 > > User Name: tux > > Host Name: NSA-Terminal-4 > > Server Name: PulseAudio (on PipeWire 0.3.74) > > Server Version: 15.0.0 > > Default Sample Specification: float32le 2ch 48000Hz > > Default Channel Map: front-left,front-right > > Default Sink: > > alsa_output.pci-0000_00_1f.3-platform-skl_hda_dsp_generic. > > HiFi__hw_sofhdadsp__sink > > Default Source: > > alsa_input.pci-0000_00_1f.3-platform-skl_hda_dsp_generic. > > HiFi__hw_sofhdadsp_6__source > > Cookie: f9dc:5e7a > > > > > > I can't figure out why this is happening. Kindly ask for any more > > information that is necessary. Thank you. > > Can you perform bisection between v6.3 and v6.4 to find the culprit (see > Documentation/admin-guide/bug-bisect.html for instructions). I did the whole process, and git bisect gave me the following potential problematic commit ID: 1bf83fa6654ce8959948878aad14a6db586125b8 Here's the link of the potential problematic commit: https://lore.kernel.org/all/20230322094346.6019-2-peter.ujfalusi@linux.intel.com/ I will be attaching the output of the git bisect command as an attachment just in case. I sincerely apologize for the delay in this reporting. Kindly ask any more information required. Thank you.
Created attachment 304661 [details] "git bisect" suggested problematic commit This is the output of the git bisect command run between mainline v6.3 and v6.4.
Furthermore, I would like to report that the latest (as of this post) 6.5 RC2 and 6.4.3 kernels still have this issue.
While following the kernel commit that "git bisect" indicated towards, I found that this issue was reported by another person. They indicated that patch 1/3 was the culprit causing this regression, as the bisection process indicated. Here's the link to that person's post: https://lore.kernel.org/all/875080d0-8771-c47f-a86b-821fe33301b0@gmail.com/ Referencing to the same commit to the kernel, there's a bug report on the SOF project's Github page: https://github.com/thesofproject/linux/issues/4455 Kindly let me know if any more information from my end is needed. Thank you.
A patch for this issue has been merged into linux-next. Here's the link to the merged patch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=90219f1bd273055f1dc1d7bdc0965755b992c045 Just a request to merge this patch into 6.5 kernel series before 6.5 is promoted to stable. A sincere thanks to everyone who worked to fix this issue!
I have this bug repeated in 6.5.7, and not repeated in 6.5, is this ok?