[Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all

[3DRaven]

On my Lenovo Legion-7-16ACHg6 laptop I can't hear any sound by internal speakers, but it work by headphones connected to standard jack aux.

uname -r
5.11.0-44-generic

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: alsa-base 1.0.25+dfsg-0ubuntu5
ProcVersionSignature: Ubuntu 5.11.0-44.48~20.04.2-generic 5.11.22
Uname: Linux 5.11.0-44-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: i3draven 1266 F.... pulseaudio
 /dev/snd/controlC0: i3draven 1266 F.... pulseaudio
 /dev/snd/controlC1: i3draven 1266 F.... pulseaudio
 /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sat Jan 15 15:10:53 2022
InstallationDate: Installed on 2021-10-11 (96 days ago)
InstallationMedia: Ubuntu 20.04.3 LTS "Focal Fossa" - Release amd64 (20210819)
PackageArchitecture: all
SourcePackage: alsa-driver
Symptom: audio
Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Generic failed
Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic
Symptom_DevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC2: i3draven 1266 F.... pulseaudio
 /dev/snd/controlC0: i3draven 1266 F.... pulseaudio
 /dev/snd/controlC1: i3draven 1266 F.... pulseaudio
 /dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio
Symptom_Jack: Speaker, Internal
Symptom_Type: No sound at all
Title: [82N6, Realtek ALC287, Speaker, Internal] No sound at all
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/08/2021
dmi.bios.release: 1.49
dmi.bios.vendor: LENOVO
dmi.bios.version: GKCN49WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Legion 7 16ACHg6
dmi.ec.firmware.release: 1.49
dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
dmi.product.family: Legion 7 16ACHg6
dmi.product.name: 82N6
dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
dmi.product.version: Legion 7 16ACHg6
dmi.sys.vendor: LENOVO

[pyronavi (pyronavi-linux-kernel-bugs)]

I get no sound via the speakers of my Lenovo Legion 7i laptop, which alsamixer tells me is using a Realtek ALC287.

I have tried various Linux distros and kernel combinations, including Ubuntu 16.04, 18.04, and 20.04, with both the default and mainline kernels (5.7.x & 5.8.x), and Manjaro with 5.6.x, 5.7.x and 5.8.x kernels.

In each case, I made sure to disable Auto-Mute in alsamixer, and turn all volume levels to maximum. In all cases, I get no sounds from the speakers (running speaker-test, playing music, etc.). I *am* able to get sound via headphones and HDMI (though I believe HDMI is via a different sound card).

Also, I can see that there is some kind of sound activity occurring when I look at pavucontrol (the reddish-orange bar that indicates a sound is playing), but there is no actual sound produced from the speakers.

My alsa-info.sh results (from Manjaro on 5.6.15) are here:

http://alsa-project.org/db/?f=ba86fe76a9d9cf1cced56600edf82eb206a36a72

I am happy to run the script again (or any other tool) from a different distro/kernel combination, please just let me know what would be helpful.

[pyronavi (pyronavi-linux-kernel-bugs)]

Update using more recent kernel:

http://alsa-project.org/db/?f=4272343a3590cc08f192f98113dedfc0418afe52

In order to provide better information, I have run alsa-info.sh from Ubuntu 20.04 running the latest mainline kernel 5.7.9-050709-generic. I have also updated the "Kernel Version" field in this bug report to reflect this.

[pyronavi (pyronavi-linux-kernel-bugs)]

I also tried with kernel 5.8.0-050800rc5-generic. Same result, no sound via speakers.

[knotted10 (knotted10-linux-kernel-bugs)]

I can confirm, same thing is happening to me, using manjaro with kernel 5.6.19-2-MANJARO

[cam (cam-linux-kernel-bugs)]

Can confirm here with Kubuntu 20.04 with kernel 5.4.0-40-generic and kernel 5.7.14... Sound works through head phones (using either bluetooth or a analog 3.5 mm cable). I did notice that playback via bluetooth stopped once... After putting the laptop to sleep then waking it back up, audio via bluetooth resumed.

I do not know if I am able to get audio via HDMI, I'm unsure how to use that setting (or is an external HDMI monitor needed for that?).

[n0.b741n37+bugzilla.kernel (n0.b741n37+bugzilla.kernel-linux-kernel-bugs)]

+1 for this on Manjaro with kernel 5.7.14.

[contact (contact-linux-kernel-bugs)]

Same issue.
I tested Manjaro with kernel 5.8.4.
Also tested Mint 20 with kernel 5.4.0-42, Ubuntu 20.04, Fedora 32 and PopOS.
Working with 3.5mm audio jack, bluetooth and docking station on USB-C.

[cam (cam-linux-kernel-bugs)]

Is everyone experiencing this on machines other than the Lenovo Legion 7i? Or is everyone on this same machine so far?

[contact (contact-linux-kernel-bugs)]

Forgot to mentioned it, Legion 7i for me.

[vince.tavernier (vince.tavernier-linux-kernel-bugs)]

Experiencing this issue (no sound on speakers, but headphones and other outputs work fine) on a Legion 7i too on my side, on Fedora 32, kernel 5.8.4-200.fc32.x86_64.

[sentinum (sentinum-linux-kernel-bugs)]

I have the exact same issue on Linux version 5.4.0-47-generic (buildd@lcy01-amd64-014) (gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)), with Lenovo Legion 7 81YT. I tried the same things as everybody else and could not get these speakers to work. I am a bit confused because some specs I found online for the the Legion 7 mention ALC 3306 -https://psref.lenovo.com/syspool/Sys/PDF/Legion/Lenovo_Legion_7_15IMHg05/Lenovo_Legion_7_15IMHg05_Spec.pdf (could not find any driver related to it) Vs ALC 287 identified by alsamixer. Speakers work just fine on Windows 10.

[kernel.org (kernel.org-linux-kernel-bugs)]

(In reply to Cameron from comment #7)
> Is everyone experiencing this on machines other than the Lenovo Legion 7i?
> Or is everyone on this same machine so far?

My issues are also present on Legion 7i (Legion 7-15IMH05 Type 81YT).

Here is my alsa-info: http://alsa-project.org/db/?f=f74d2b20683de3bc0daab8c4740f34a66955ba70

A notable thing is that i *DID* have speaker audio for a couple of weeks (headphones have always worked), until it suddenly stopped working again. My guess is that there might have been regression due to some package being updated but I could not find any meaningful culprit.

I can paste the hidden BIOS HD audio settings for this configuration if that's of any use.

Kernel is 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS

[pyronavi (pyronavi-linux-kernel-bugs)]

(In reply to kernel.org from comment #11)
> (In reply to Cameron from comment #7)
> > Is everyone experiencing this on machines other than the Lenovo Legion 7i?
> > Or is everyone on this same machine so far?
>
> My issues are also present on Legion 7i (Legion 7-15IMH05 Type 81YT).
>
> Here is my alsa-info:
> http://alsa-project.org/db/?f=f74d2b20683de3bc0daab8c4740f34a66955ba70
>
> A notable thing is that i *DID* have speaker audio for a couple of weeks
> (headphones have always worked), until it suddenly stopped working again.
> My guess is that there might have been regression due to some package being
> updated but I could not find any meaningful culprit.
>
> I can paste the hidden BIOS HD audio settings for this configuration if
> that's of any use.
>
> Kernel is 5.4.0-47-generic #51-Ubuntu SMP Fri Sep 4 19:50:52 UTC 2020 x86_64
> x86_64 x86_64 GNU/Linux
>
> Distributor ID: Ubuntu
> Description: Ubuntu 20.04.1 LTS

Do you have any details for the time period that you did have sound? Was it a fresh install of Ubuntu 20.04.1? Did you allow internet updates during install? If you still have the ISO you used, I'd also like to confirm the hash of the file. If we can reproduce it, we'll be a lot closer to a solution.

[pyronavi (pyronavi-linux-kernel-bugs)]

Also, regarding the advanced BIOS settings, there are several sound modes you switch the laptop into.

I tried a few but didn't get anything to work. I'm not very knowledgeable in this area though.

Accessing advanced BIOS is documented here:

>Advanced BIOS options can be accessed by going into more settings, hold down
>Fn and press each key horizontally from q to p, a to l, then z to m, let go of
>Fn and press F10. Click save changes and reboot into BIOS. Advanced settings
>will now be available.

https://wiki.archlinux.org/index.php/Lenovo_Legion_7i

[cam (cam-linux-kernel-bugs)]

For convenience, here's how to navigate to the audio settings under the advanced BIOS settings:
Advanced -> PCH-IO -> HD Audio Configuration

I going to attach pictures showing the top level Audio menu. There's quite a bit more settings under the sub-menus though.

It's worth mentioning that in my experience that many settings available under the advance BIOS settings do not seem to work. I haven't tried any of the audio settings yet (and there are quite a few), but in general many settings probably only apply to certain models of laptop aside from the Legion 7i. Presumably at least some of the audio settings should work though.

[cam (cam-linux-kernel-bugs)]

Created attachment 292497
Top half of top level audio level

[cam (cam-linux-kernel-bugs)]

Created attachment 292499
bottom half of the top level audio menu

[cam (cam-linux-kernel-bugs)]

About how long have you had your Legion? I've had mine since August 6th IIRC, and I've always had this problem. Could help narrow down the window.

Could this be possibly related to a BIOS update?

> A notable thing is that i *DID* have speaker audio for a couple of weeks
> (headphones have always worked), until it suddenly stopped working again.
> My guess is that there might have been regression due to some package being
> updated but I could not find any meaningful culprit.

[kernel.org (kernel.org-linux-kernel-bugs)]

(In reply to Cameron from comment #17)
> About how long have you had your Legion? I've had mine since August 6th
> IIRC, and I've always had this problem. Could help narrow down the window.
>
> Could this be possibly related to a BIOS update?
>
> > A notable thing is that i *DID* have speaker audio for a couple of weeks
> > (headphones have always worked), until it suddenly stopped working again.
> > My guess is that there might have been regression due to some package being
> > updated but I could not find any meaningful culprit.

I got mine in the beginning of August. Updated immediately to 2.02 BIOS.

I had already prepared for not having sound as I had read the Arch Wiki page, and was really struck with a surprise as one day after playing with merely the ubuntu sound settings (fiddling with system sound volume) the speakers suddenly started working. I did not make any notes of the occasion as I assumed there might have been a recent kernel or some other package update, and did not expect any regressions to occur. But they did a couple of weeks later and that's when I found this ticket for ALC287.

What makes tracking this down a bit trickier than just booting with earlier kernel packages is that I have fiddled with both alsa and pulse on the system (e.g. tried different kernel module options for snd-hda-intel) so my working state was never a vanilla install with some updates. I will nevertheless try to get back to a working configuration with some kernel and report back.

[cam (cam-linux-kernel-bugs)]

I immediately upgraded to 2.02 as well... But tried reverting to the previous version (2.01 probably?) to test something unrelated. That didn't fix my issues.

Anyway, might be worth looking at /var/log/dpkg.log* to see what had been installed/updated around that time frame. I've skimmed through and so far the only thing that stands out are some pulse audio updates on July 23rd. So unless you don't update frequently, that's probably not it.

> What makes tracking this down a bit trickier than just booting with earlier
> kernel packages is that I have fiddled with both alsa and pulse on the
> system (e.g. tried different kernel module options for snd-hda-intel) so my
> working state was never a vanilla install with some updates. I will
> nevertheless try to get back to a working configuration with some kernel and
> report back.

[ealex95 (ealex95-linux-kernel-bugs)]

I'm having the same issue on a Lenovo Legion 7-15IMHg05. I just got it this week (22nd september) and installed Arch Linux on it straight away. I tried fiddling with alsamixer and pavucontrol settings, no change. I tried different kernel packages (linux 5.8.10, linux-lts 5.4.66, linux-xanmod 5.8.10/11), no dice. I did not update the BIOS yet and the current version is "E9CN32WW(V2.00)", so this probably rules out a BIOS regression.

My alsa-info: http://alsa-project.org/db/?f=60beb004225ca38c49bb6a1495e6cd713a1a4f1e

I did not test the laptop with Windows yet, but I will try to do this soon.

[pyronavi (pyronavi-linux-kernel-bugs)]

Perhaps there is a way to force ALSA to recognize the card as an ALC3306. As Fab mentioned, the specs do seem to indicate that as the sound device.

[cam (cam-linux-kernel-bugs)]

Did you find this in the documentation? I haven't found any references
to ALC3306 on my system

Doing a quick search for ALC3306, the only references that come up are
for the Lenovo Legion 7 and the Yoga Slim 7.  The ALC3306 seems to be
pretty uncommon and pretty new.

Doing a bit of research, sounds like audio works on the Yoga Slim 7.
Possibly a red herring..?

On 9/25/20 7:38 PM, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #21 from <email address hidden> ---
> Perhaps there is a way to force ALSA to recognize the card as an ALC3306. As
> Fab mentioned, the specs do seem to indicate that as the sound device.
>

[pyronavi (pyronavi-linux-kernel-bugs)]

(In reply to Cameron from comment #22)
> Did you find this in the documentation? I haven't found any references
> to ALC3306 on my system
>
> Doing a quick search for ALC3306, the only references that come up are
> for the Lenovo Legion 7 and the Yoga Slim 7.  The ALC3306 seems to be
> pretty uncommon and pretty new.
>
> Doing a bit of research, sounds like audio works on the Yoga Slim 7.
> Possibly a red herring..?
>
> On 9/25/20 7:38 PM, <email address hidden> wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=208555
> >
> > --- Comment #21 from <email address hidden> ---
> > Perhaps there is a way to force ALSA to recognize the card as an ALC3306.
> As
> > Fab mentioned, the specs do seem to indicate that as the sound device.
> >

My mistake. I must have seen "Legion 7" and mistaken it for the 7i.

Also, I have just sent an email to the members of the ALSA team. Hopefully someone will reply soon.

[ealex95 (ealex95-linux-kernel-bugs)]

> I did not test the laptop with Windows yet, but I will try to do this soon.

Tested now, it works fine on Windows. I also updated the bios to E9CN58WW(V4.03), still doesn't work on Linux.

[cam (cam-linux-kernel-bugs)]

I think the 7 and 7i are the same. In the case of the Legion 5/5i, the i
differentiates between the AMD and Intel versions. However, I believe
there's still no plans to make an AMD version of the Legion 7.

My point was that sound seems to work on the Yoga 7 under Linux, which
also has the ALC3306 so maybe it's not related to the ALC3306 codec.

On 9/26/2020 7:43 AM, <email address hidden> wrote:
> My mistake. I must have seen "Legion 7" and mistaken it for the 7i.

[erkanadali91 (erkanadali91-linux-kernel-bugs)]

I am having same issue with Lenovo Legion 7. Another friend that use the same laptop also having that problem too. I hope they can fix this issue.

[fodor18zoltan (fodor18zoltan-linux-kernel-bugs)]

I am also facing same issue on Ubuntu 20.04 with Legion 7i. Never worked on Linux.

Alsa info http://alsa-project.org/db/?f=286348226d62d73c2aa3987794adfde7ef78095e
Linux archy-Lenovo-Legion-7-15IMHg05 5.9.2-050902-generic #202010290646 SMP Thu Oct 29 11:11:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Przemek K. (azrael)]

I have the same issue.
I have a Legion 7 16ACHg6 (82N6007CPB) which I'm testing under Ubuntu 20.04.3 LTS and 21.10 LiveUSB, and in both of them there is no sound out of the built-in speakers. Headphones are working fine though.
05:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) HD Audio Controller
hwinfo shows that there is a "Realtek ALC701" chip in this laptop.
Full hwinfo output attached.

[Przemek K. (azrael)]

This might be another case of https://bugzilla.kernel.org/show_bug.cgi?id=208555

[Przemek K. (azrael)]

Alsa-info output: http://alsa-project.org/db/?f=ae148d86e41375195a7e401ef0af5d533218f275

[Przemek K. (azrael)]

Alsa-info output saved to a file

[Przemek K. (azrael)]

ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu70
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: ubuntu 5091 F.... pulseaudio
 /dev/snd/pcmC1D0p: ubuntu 5091 F...m pulseaudio
 /dev/snd/controlC0: ubuntu 5091 F.... pulseaudio
CasperMD5CheckResult: pass
CasperVersion: 1.465
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 21.10
LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
Package: alsa-driver (not installed)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
Tags: impish
Uname: Linux 5.13.0-19-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
_MarkForUpload: True
dmi.bios.date: 11/08/2021
dmi.bios.release: 1.49
dmi.bios.vendor: LENOVO
dmi.bios.version: GKCN49WW
dmi.board.asset.tag: NO Asset Tag
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.asset.tag: NO Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Legion 7 16ACHg6
dmi.ec.firmware.release: 1.49
dmi.modalias: dmi:bvnLENOVO:bvrGKCN49WW:bd11/08/2021:br1.49:efr1.49:svnLENOVO:pn82N6:pvrLegion716ACHg6:skuLENOVO_MT_82N6_BU_idea_FM_Legion716ACHg6:rvnLENOVO:rnLNVNB161216:rvrSDK0R32862WIN:cvnLENOVO:ct10:cvrLegion716ACHg6:
dmi.product.family: Legion 7 16ACHg6
dmi.product.name: 82N6
dmi.product.sku: LENOVO_MT_82N6_BU_idea_FM_Legion 7 16ACHg6
dmi.product.version: Legion 7 16ACHg6
dmi.sys.vendor: LENOVO

[Przemek K. (azrael)]

apport information

[Przemek K. (azrael)]

apport information

[Przemek K. (azrael)]

apport information

[Przemek K. (azrael)]

apport information

[Przemek K. (azrael)]

apport information

[soyer (soyer-linux-kernel-bugs)]

Could you share your acpidump output?

[kernel (kernel-linux-kernel-bugs)]

(In reply to thornley.david from comment #819)
> I am running an 14IRP8 (Yoga Pro/Slim 9i), specifically this model
> (https://psref.lenovo.com/Detail/Yoga/Yoga_Pro_9_14IRP8?M=83BU0024AU).
>
> I have the laptop running Ubuntu 23.10 and I run mainline kernels from
> Ubuntu. I have tried almost every recent kernel build up until 6.8-rc5 today
> (I had read that 6.8 was supposed to fix this issue). Audio is still running
> only the tweaters, zero bass.
>
> I've tried many things, notably the snd.conf (options
> snd-sof-intel-hda-common hda_model=alc287-yoga9-bass-spk-pin) to no avail.
> Also tried noble's firmware-sof-signed package, manually tweaking the amixer
> configuration.
>
> My alsa info ->
> https://alsa-project.org/db/?f=634d31445ad5a7c4a023cdb15a07dea2a4048437
>
> Thanks!!

Do you have full volume sound? I have a similar model (https://psref.lenovo.com/Detail/Lenovo/Lenovo_Slim_Pro_9_14IRP8?M=83BV0002US) and had to do a few things to make the amplifier work in the first place, but I still don't have any bass.

To get sound on linux 6.7 I had to update the firmware files and use `options snd-sof-intel-hda-common hda_model=17aa:38be`, which had a different effect to alc287-yoga9-bass-spk-pin (not sure why). I described with more details at https://github.com/PJungkamp/yoga9-linux/issues/11#issuecomment-1899400594

I didn't try a lot on 6.8 but my current config doesn't fix the bass there too.

[thornley.david (thornley.david-linux-kernel-bugs)]

I do now :) You're right the hda_model=17aa:38be definitely forces the tas driver to load properly (it is in dmesg) and the firmware link seemed to fix a NULL error when I first tried it.

[ 5.770034] snd_hda_codec_realtek ehdaudio0D0: bound i2c-TIAS2781:00 (ops tas2781_hda_comp_ops [snd_hda_scodec_tas2781_i2c])

I tried both 6.8.0-rc5 and then fell back to 6.7.5 because in both of these the volume control didn't work at all (seems to be at full volume), even in "alsamixer -c 1". Note that originally, the sound was low/quiet but volume control did work.

[soyer (soyer-linux-kernel-bugs)]

Could someone please test if changing this fixup in the sound/pci/hda/patch_realtek.c fixes the volume control?

 [ALC287_FIXUP_TAS2781_I2C] = {
  .type = HDA_FIXUP_FUNC,
  .v.func = tas2781_fixup_i2c,
  .chained = true,
  .chain_id = ALC269_FIXUP_THINKPAD_ACPI,
 },

to this:

 [ALC287_FIXUP_TAS2781_I2C] = {
  .type = HDA_FIXUP_FUNC,
  .v.func = tas2781_fixup_i2c,
  .chained = true,
  .chain_id = ALC285_FIXUP_THINKPAD_HEADSET_JACK,
 },

It worked for ALC287_FIXUP_YOGA7_14ARB7_I2C.

[kernel (kernel-linux-kernel-bugs)]

(In reply to Gergo K from comment #826)
> Could someone please test if changing this fixup in the
> sound/pci/hda/patch_realtek.c fixes the volume control?
>
> [ALC287_FIXUP_TAS2781_I2C] = {
> .type = HDA_FIXUP_FUNC,
> .v.func = tas2781_fixup_i2c,
> .chained = true,
> .chain_id = ALC269_FIXUP_THINKPAD_ACPI,
> },
>
> to this:
>
> [ALC287_FIXUP_TAS2781_I2C] = {
> .type = HDA_FIXUP_FUNC,
> .v.func = tas2781_fixup_i2c,
> .chained = true,
> .chain_id = ALC285_FIXUP_THINKPAD_HEADSET_JACK,
> },
>
> It worked for ALC287_FIXUP_YOGA7_14ARB7_I2C.

Just tried it and it indeed works, nice! Do you know if this will be merged soon (hopefully before 6.8 release)?

It still requires `options snd-sof-intel-hda-common hda_model=17aa:38be` (doing nothing or using `hda_model=alc287-yoga9-bass-spk-pin` doesn't work). But now I can control the volume using the default "Play HiFi quality Music" without janky work around.

[soyer (soyer-linux-kernel-bugs)]

Great to hear!
I can create a patch, and it can be included in 6.6 and 6.7.

Can you test whether the headset jack works also?

And could you run alsa-info.sh? I think your model needs to be added to the patch_realtek.c to make it work without the module parameters.

[kernel (kernel-linux-kernel-bugs)]

(In reply to Gergo K from comment #828)
> Great to hear!
> I can create a patch, and it can be included in 6.6 and 6.7.
>
> Can you test whether the headset jack works also?
>
> And could you run alsa-info.sh? I think your model needs to be added to the
> patch_realtek.c to make it work without the module parameters.

I can confirm that headset jack works perfectly with this patch. With 6.7 it didn't even detect the headset plugged (didn't test it on 6.8 without the patch).

Here is the alsa-info after the patch: http://alsa-project.org/db/?f=4bdd25202b2329c03bef10d0f6f0b4781987aa49

Thank you for your attention!

[soyer (soyer-linux-kernel-bugs)]

I don't know why it won't pick up your model.
Could you please run alsa-info after the patch and without the module parameter?

[kernel (kernel-linux-kernel-bugs)]

=(In reply to Gergo K from comment #830)
> I don't know why it won't pick up your model.
> Could you please run alsa-info after the patch and without the module
> parameter?

Yeah, I have no idea, I decided to use specifically the model of my speaker through trial and error.
http://alsa-project.org/db/?f=93ba55541edee13c680039a8c00ff85930f37ad8

I don't know how but the bass on Windows is still much better and I always hear a strong beep from both speakers when I get past the sddm lock screen when I turn on the laptop.

[cam (cam-linux-kernel-bugs)]

The strong beep suggests you might have the older firmware.

If you have the old firmware, you might also notice your sound for your
left and right speakers are swapped.

On 2/22/24 12:06, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #831 from Willian (<email address hidden>) ---
> =(In reply to Gergo K from comment #830)
>> I don't know why it won't pick up your model.
>> Could you please run alsa-info after the patch and without the module
>> parameter?
> Yeah, I have no idea, I decided to use specifically the model of my speaker
> through trial and error.
> http://alsa-project.org/db/?f=93ba55541edee13c680039a8c00ff85930f37ad8
>
>
> I don't know how but the bass on Windows is still much better and I always
> hear
> a strong beep from both speakers when I get past the sddm lock screen when I
> turn on the laptop.
>

[kernel (kernel-linux-kernel-bugs)]

(In reply to Cameron Berkenpas from comment #832)
> The strong beep suggests you might have the older firmware.
>
> If you have the old firmware, you might also notice your sound for your
> left and right speakers are swapped.

The speakers are not swapped but how can I check the current version and update these firmwares?

I moved the firmwares from https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2 to /usr/lib/firmware, so not sure if this affected something.

[cam (cam-linux-kernel-bugs)]

Then that's the latest firmware as far as I know (that's my server lol).

Not sure why you're getting the beep then.

On 2/22/24 13:31, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #833 from Willian (<email address hidden>) ---
> (In reply to Cameron Berkenpas from comment #832)
>> The strong beep suggests you might have the older firmware.
>>
>> If you have the old firmware, you might also notice your sound for your
>> left and right speakers are swapped.
> The speakers are not swapped but how can I check the current version and
> update
> these firmwares?
>
> I moved the firmwares from
> https://neo-zeon.de/~hiryu/tas/firmware-6.6.tar.bz2
> to /usr/lib/firmware, so not sure if this affected something.
>

[soyer (soyer-linux-kernel-bugs)]

The latest firmware is probably in the linux-firmware package.
Do you still hear a difference when you disable Dolby in Windows?
Do you hear the beep after hibernation also?

[soyer (soyer-linux-kernel-bugs)]

Could you please comment out this line from patch_realtek.c and rebuild the kernel and start it without the module parameters?

 SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021", ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),

[kernel (kernel-linux-kernel-bugs)]

(In reply to Cameron Berkenpas from comment #834)
> Then that's the latest firmware as far as I know (that's my server lol).
>
> Not sure why you're getting the beep then.

Oh, didn't know the server was yours, thank you lol. Unfortunately, the firmwares are not up to date compared to kernel-firmwares. Specifically the files TAS2XXX3881.bin, TAS2XXX38CB.bin, TAS2XXX38CD.bin, TIAS2781RCA2.bin.

Updating the firmwares fixed the loud beep (which also sounds like something really broken) and my bass is much better than before. As a very subject comparison, the working bass at low volume makes my table shake a little, the old firmware sounds flat and doesn't move anything even at the highest volume. Windows is still a little better but probably because of the tuning than anything else.

I tested the new firmware without the module parameter just in case it also fixes that, but it still doesn't work without it.

(In reply to Gergo K from comment #836)
> Could you please comment out this line from patch_realtek.c and rebuild the
> kernel and start it without the module parameters?
>
> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021",
> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),

I will test it right now.

[cam (cam-linux-kernel-bugs)]

Sounds like I should try this new firmware...

kernel-firmware... Is that the repo?

On 2/22/24 6:56 PM, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #837 from Willian (<email address hidden>) ---
> (In reply to Cameron Berkenpas from comment #834)
>> Then that's the latest firmware as far as I know (that's my server lol).
>>
>> Not sure why you're getting the beep then.
> Oh, didn't know the server was yours, thank you lol. Unfortunately, the
> firmwares are not up to date compared to kernel-firmwares. Specifically the
> files TAS2XXX3881.bin, TAS2XXX38CB.bin, TAS2XXX38CD.bin, TIAS2781RCA2.bin.
>
> Updating the firmwares fixed the loud beep (which also sounds like something
> really broken) and my bass is much better than before. As a very subject
> comparison, the working bass at low volume makes my table shake a little, the
> old firmware sounds flat and doesn't move anything even at the highest
> volume.
> Windows is still a little better but probably because of the tuning than
> anything else.
>
> I tested the new firmware without the module parameter just in case it also
> fixes that, but it still doesn't work without it.
>
>
> (In reply to Gergo K from comment #836)
>> Could you please comment out this line from patch_realtek.c and rebuild the
>> kernel and start it without the module parameters?
>>
>> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021",
>> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),
> I will test it right now.
>

[kernel (kernel-linux-kernel-bugs)]

(In reply to Gergo K from comment #836)
> Could you please comment out this line from patch_realtek.c and rebuild the
> kernel and start it without the module parameters?
>
> SND_PCI_QUIRK(0x17aa, 0x3802, "Lenovo Yoga DuetITL 2021",
> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS),

http://alsa-project.org/db/?f=8d9465f9d22c4efdc3655373f1d32416516afacd

Yeah, it works! I'm curious what was the issue, can you give an overview of it?

(In reply to Cameron Berkenpas from comment #838)
> Sounds like I should try this new firmware...
>
>
> kernel-firmware... Is that the repo?

https://gitlab.com/kernel-firmware/linux-firmware

[soyer (soyer-linux-kernel-bugs)]

There is an ID collision.

Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI SSID before the Codec SSID in the same table. So it picks the ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C.

!!PCI Soundcards installed in the system
!!--------------------------------------

00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device [8086:51cf] (rev 01)
 Subsystem: Lenovo Device [17aa:3802]

I think a common fixup can be figured out, or a better solution from someone who knows this subsystem well.

[kernel (kernel-linux-kernel-bugs)]

(In reply to Gergo K from comment #840)
> There is an ID collision.
>
> Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga
> DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI
> SSID before the Codec SSID in the same table. So it picks the
> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C.
>
>
> !!PCI Soundcards installed in the system
> !!--------------------------------------
>
> 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device
> [8086:51cf] (rev 01)
> Subsystem: Lenovo Device [17aa:3802]
>
> I think a common fixup can be figured out, or a better solution from someone
> who knows this subsystem well.

Hm I see, not sure if this is the right place to talk about the code, but is there a reason for the fixup table to be the same for PCI and Codec SSIDs? (I know it's not like it could be separated at this point). Also, is there a reason to match by PCI before Codec? A few ideas I thought:

1. Just check if the PCI and Codec SSID match the exact SSIDs of this device (not elegant)
2. For every lookup, check with both

[kernel (kernel-linux-kernel-bugs)]

(In reply to Gergo K from comment #840)
> There is an ID collision.
>
> Your audio controller's PCI SSID (17aa:3802) is the same as the "Lenovo Yoga
> DuetITL 2021" Codec SSID. The snd_hda_pick_fixup() function searches the PCI
> SSID before the Codec SSID in the same table. So it picks the
> ALC287_FIXUP_YOGA7_14ITL_SPEAKERS fixup not the ALC287_FIXUP_TAS2781_I2C.
>
>
> !!PCI Soundcards installed in the system
> !!--------------------------------------
>
> 00:1f.3 Multimedia audio controller [0401]: Intel Corporation Device
> [8086:51cf] (rev 01)
> Subsystem: Lenovo Device [17aa:3802]
>
> I think a common fixup can be figured out, or a better solution from someone
> who knows this subsystem well.

Hm I see, not sure if this is the right place to talk about the code, but is there a reason for the fixup table to be the same for PCI and Codec SSIDs? (I know it's not like it could be separated at this point). Also, is there a reason to match by PCI before Codec? A few ideas I was thinking:

1. Just check if the PCI and Codec SSID match the exact SSIDs of this device - not elegant
2. For every lookup, check with both PCI and Codec SSID and see if they match the same entry, add a debug to these cases and use the Codec entry - not sure how common this is and if this will break other cases

Depending on how hard this problem is I may want to help with the code if possible.

(sorry for the dupe, I pressed the save changes by mistake before)

[soyer (soyer-linux-kernel-bugs)]

I don't know the reasons, but this code has been working in this way for 10+ years, so this type of collision can not be common.

I sent the ALC285_FIXUP_THINKPAD_HEADSET_JACK patch to the lists:
https://lore.kernel.org/all<email address hidden>/

And I sent a question about how to handle this collision:
https://lore<email address hidden>/

If you are interested in linux sound development, you can subscribe to the linux-sound list:
http://vger.kernel.org/vger-lists.html#linux-sound

[thornley.david (thornley.david-linux-kernel-bugs)]

I also tried the two changes above to 6.7.6, it took a bit for me to work out how to compile a custom kernel in ubuntu (easy once you know). Mine is a slightly different 14IRP8 device Yoga Pro rather than Slim Pro (same underlying hardware).

Alsa-info -> https://alsa-project.org/db/?f=3adac42b53db18376ea17cd5ab008c247a4039a5

Applied the latest firmware to /lib/firmware from https://gitlab.com/kernel-firmware/linux-firmware.git (branch main).

Confirmed no options are now required, overall sound is considerably better, volume works, headphones also work.

Subjectively audio doesn't seem quite as good as in Windows, where the bass seems to get dynamically adjusted depending on the volume (maybe some fancy DSP effects, not sure - I am only guessing). Either way, it is now light-years better than what it was before the changes.

Many thanks Gergo K. :)

[thornley.david (thornley.david-linux-kernel-bugs)]

FYI, this looks to have been improved in Ubuntu's 6.8.1 mainline (https://kernel.ubuntu.com/mainline/v6.8.1/).

[Giulio Iannelli (opisthofulax)]

I will share my experience maybe it can help. I am running this configuration

CPU: 8-core AMD Ryzen 7 5800H with Radeon Graphics (-MT MCP-)
speed/min/max: 400/400/4463 MHz Kernel: 6.5.0-26-generic x86_64 Up: 10m
Mem: 3724.7/64145.7 MiB (5.8%) Storage: 2.75 TiB (59.2% used) Procs: 378
Shell: Bash inxi: 3.3.13

a Lenovo 82N6 Legion 7 16ACHg6. Now in kernel 5.15 the sound was back but external displays could not be detected. Can we use the sound ports of kernel 5.15 in kernel 6.5+? It would be awesome to finally see audio and video working at the same time on my machine.

[thornley.david (thornley.david-linux-kernel-bugs)]

FYI, broken again in 6.8.4, 6.8.3 (not sure about 6.8.2).

[hyc (hyc-linux-kernel-bugs)]

Hm, I installed Ubuntu's 6.8.4 and the speakers work on my Legion 7 16achg6. But suspend doesn't wake up, so I'm back on 5.17.

[dlinuigh (dlinuigh-linux-kernel-bugs)]

After I upgrade to Linux 6.8.5, the speakers work well on my laptop. LOL, btw the machine can wake up from suspend, so this is also fixed. My laptop hardware model is Lenovo Legion R9000X ARHA7. Thanks everyone.

[thornley.david (thornley.david-linux-kernel-bugs)]

Working fine again for me in 6.8.5 :) Sorry for the spam!

[tuupic (tuupic-linux-kernel-bugs)]

(In reply to Linghui Ding from comment #848)
> After I upgrade to Linux 6.8.5, the speakers work well on my laptop. LOL,
> btw the machine can wake up from suspend, so this is also fixed. My laptop
> hardware model is Lenovo Legion R9000X ARHA7. Thanks everyone.

Confirm. Lenovo Legion 7 slim (R9000X) 16ARHA7. Speakers start working since upgrading to 6.8.5 kernel.

But internal microphone doesn't. But maybe it's some local problem, I have never checked it before.

[admin (admin-linux-kernel-bugs)]

Can confirm on Endeavour 6.8.5 that my Legion Slim 7 16arha7 has working speakers now! yay! Lets hope they don't break again...

[tuupic (tuupic-linux-kernel-bugs)]

(In reply to admin from comment #851)
> Can confirm on Endeavour 6.8.5 that my Legion Slim 7 16arha7 has working
> speakers now! yay! Lets hope they don't break again...

Does internal microphone work in your OS ?

[dreamsyntax (dreamsyntax-linux-kernel-bugs)]

Hi, just confirming that on:
Lenovo Legion Pro 7i (Gen 8 / 2023) the no sound issue has regressed again on 6.8.5.

Last working version without any issues is 6.7.9 - which is odd considering the original post lists this as not a regression?

alsamixer shows ALC287 under system info.

6.8.2-6.8.4 have no audio for me.
6.8.5 has audio on reboot, but after a seemingly random amount of time the audio will no longer function until next reboot.

6.7.9 works at all times for me.

[cam (cam-linux-kernel-bugs)]

(In reply to dreamsyntax from comment #853)
> Hi, just confirming that on:
> Lenovo Legion Pro 7i (Gen 8 / 2023) the no sound issue has regressed again
> on 6.8.5.
>
> Last working version without any issues is 6.7.9 - which is odd considering
> the original post lists this as not a regression?
>
> alsamixer shows ALC287 under system info.
>
>
> 6.8.2-6.8.4 have no audio for me.
> 6.8.5 has audio on reboot, but after a seemingly random amount of time the
> audio will no longer function until next reboot.
>
> 6.7.9 works at all times for me.

I also have the Legion Pro 7i Gen 8 16IRX8H, sound worked through all those kernel versions for me... But I do have another problem I wonder if it's related... Occasionally, my sound will just stop working. I can't get it working until I reboot... This tends to happen at a rate of less than once per day.

Last time it happened was yesterday. This time I decided to enable hibernate to see if resume from that would restore my sound (resuming from sleep doesn't work).

Anyway, the issue didn't happen to me for about a month... and then happened to me twice recently. Maybe it started around 6.8.4 or 6.8.5? When it happened yesterday, I was on 6.8.6.

The problem is so intermittent it's hard to pin it down to it starting with a specific kernel version...

But it makes me think maybe our problems are symptoms of the same issue.

How are you getting recent kernels? Are you self compiling? Are you using the Ubuntu mainline repo? Something else and/or some other distro entirely?

I'm compiling my own.

When this happens, audacious gives me some ALSA input/output error. I suspect some hook to tell the amps to wake up and play audio through the speakers hangs, but that's all I've got so far.

But sound issues related to TI's smart amps are definitely unrelated to this bug we're posting in. Someone should start a new bug for these issues if we hope to get more support.

[dreamsyntax (dreamsyntax-linux-kernel-bugs)]

Created attachment 306161
attachment-31010-0.html

> ...it makes me think maybe our problems are symptoms of the same issue

I agree. I am using endeavour os, but I've also verified my scenario on
nobara (fedora based).

I found I can somewhat reliably get the audio to fail on 6.8.5 by leaving
the system muted for a few minutes. Additionally something I noticed on
6.8.0 is running a video in a Firefox based browser (I used Librewolf),
pausing and unpausing could lead to the sound being permanently disabled
for the whole system until reboot.

I am not self compiling, just using the arch linux and linux-headers
packages. If this bug tracker is for debian/ubu based distros only, my bad.
The issue is reproducible regardless.
I can only confirm that I experience no issue on 6.7.9 on fedora based
distros and arch. I think I had no luck using 6.7.9 on linux mint (using
mainline kernel), but I assume it is because of an outdated linux-firmware
package.

If it isn't a pain for you to test, could you try 6.7.9 and see if you
experience no issues as well?

[cam (cam-linux-kernel-bugs)]

I can try 6.7.9 and 6.7.12.

What you described vaguely sounds like the stuff I'm doing when it
breaks on me so I'll try that too!

I might have some time to do this tomorrow night.

I've wondered if this is a firmware issue as well. Here are my md5sums
for my files:
af5adf85ef96839ae1aa79bc916f1b91  TAS2XXX387D.bin
951a483a58b1b41e5114f0c0746f583a  TAS2XXX387E.bin
f7f319ba68ab37e093381360e2bdefff  TAS2XXX3881.bin
dfb907ce0135030182704cabb1223465  TAS2XXX3884.bin
a7ebbd19c73cd6fea005bcab025f4921  TAS2XXX3886.bin
f1f0486569020316a7b3253db17c6b94  TAS2XXX38A7.bin
b796beae38a02fa27426560742a829b6  TAS2XXX38A8.bin
830cf65b0d6e2355b70b9ed364b4819d  TAS2XXX38B8.bin
2a4d57199bc04ebc2dd9880f7afee4a7  TAS2XXX38B9.bin
fcaa167bb712cbe7829ae41f9ea7bfa0  TAS2XXX38BA.bin
9a6089a79ef6038691733a18c94c1005  TAS2XXX38BB.bin
0ace13d455c64d5043ac2ee066555f20  TAS2XXX38BE.bin
a90c1c801076cf6f2acfd6edf83e7575  TAS2XXX38BF.bin
3723cbf4848c3df69cd870314817aada  TAS2XXX38C3.bin
dfb907ce0135030182704cabb1223465  TAS2XXX38CB.bin
a7ebbd19c73cd6fea005bcab025f4921  TAS2XXX38CD.bin
33c27f3eec9e46e1e487b0fc4b781725  TIAS2781RCA2.bin
4824e06b5919b577d4671a3dd40fbda4  TIAS2781RCA2.json
61dcfeb8c3dd4c5b922dbbe8d826d2ef  TIAS2781RCA4.bin
38f473162f7dd3546db9ee561fb560bf  TIAS2781RCA4.json

I've considered and looking at the latest files in the linux-firmware
git repo, but haven't had time yet.

On 4/15/2024 10:19 PM, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #855 from <email address hidden> ---
>> ...it makes me think maybe our problems are symptoms of the same issue
> I agree. I am using endeavour os, but I've also verified my scenario on
> nobara (fedora based).
>
> I found I can somewhat reliably get the audio to fail on 6.8.5 by leaving
> the system muted for a few minutes. Additionally something I noticed on
> 6.8.0 is running a video in a Firefox based browser (I used Librewolf),
> pausing and unpausing could lead to the sound being permanently disabled
> for the whole system until reboot.
>
> I am not self compiling, just using the arch linux and linux-headers
> packages. If this bug tracker is for debian/ubu based distros only, my bad.
> The issue is reproducible regardless.
> I can only confirm that I experience no issue on 6.7.9 on fedora based
> distros and arch. I think I had no luck using 6.7.9 on linux mint (using
> mainline kernel), but I assume it is because of an outdated linux-firmware
> package.
>
> If it isn't a pain for you to test, could you try 6.7.9 and see if you
> experience no issues as well?
>

[soyer (soyer-linux-kernel-bugs)]

The firmware files have not changed.

I think it's possible that this commit is the culprit:
https://github.com/torvalds/linux/commit/bec7760a6c5fa59593dac264fa0c628e46815986

Sorry about that, it works fine with tas2563, but I couldn't test it with tas2781.
Something related to power management can cause this also.

Please try the following and report if it fixes the issue:

amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1

It is possible that the -c 1 and the numid parameters are not exactly these, they can be obtained from `amixer -c 1 contents` or `amixer -c 0 contents`.

Thanks,
Gergo

[cam (cam-linux-kernel-bugs)]

I had some time this morning to try and repeat the issue.. I couldn't do it. So until I can find a way to repeat it, it's not worth testing other kernel releases.

I will try Gergo's command once it happens again and report back.

[soyer (soyer-linux-kernel-bugs)]

What else came to mind, the driver currently writes the calibration data to one of the wrong registers of tas2781, which can also cause problems. If anyone wants to know what fixes the problem, please try this patch as well:

https://<email address hidden>/

[cam (cam-linux-kernel-bugs)]

On 4/16/24 16:54, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #859 from Gergo K (<email address hidden>) ---
> What else came to mind, the driver currently writes the calibration data to
> one
> of the wrong registers of tas2781, which can also cause problems. If anyone
> wants to know what fixes the problem, please try this patch as well:
>
> https://<email address hidden>/
>
Pretty good find/catch! I checked the source of my current kernel
(6.8.6) and it didn't have that patch installed... So I applied it.
We'll see how this goes...

[dreamsyntax (dreamsyntax-linux-kernel-bugs)]

> Please try the following and report if it fixes the issue:
> amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1

What is the expected result of the above?

> I had some time this morning to try and repeat the issue.. I couldn't do it

I can reproduce in < 5 mins on average.

I played a video and paused / resumed after a while, until the issue kicked in.
Ran: `amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1`
No effect, sound still broken. The output looked ok.
Checked both `amixer -c 1 contents` or `amixer -c 0 contents`. - there
are a lot of entries, what exactly am I looking for?

Here's the interesting part though:
In that same session, I made the laptop close lid action + sleep
On wake, audio was working again.