[Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No sound at all
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
sound-2.6 (alsa-kernel) |
Confirmed
|
Medium
|
|||
alsa-driver (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
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+
ProcVersionSign
Uname: Linux 5.11.0-44-generic x86_64
NonfreeKernelMo
ApportVersion: 2.20.11-
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
/dev/snd/
/dev/snd/pcmC1D0p: i3draven 1266 F...m pulseaudio
CasperMD5CheckR
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)
PackageArchitec
SourcePackage: alsa-driver
Symptom: audio
Symptom_
Symptom_Card: Family 17h (Models 10h-1fh) HD Audio Controller - HD-Audio Generic
Symptom_
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/
/dev/snd/
/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.
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.ec.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.family: Legion 7 16ACHg6
dmi.product.name: 82N6
dmi.product.sku: LENOVO_
dmi.product.
dmi.sys.vendor: LENOVO
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #13 |
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #14 |
Update using more recent kernel:
http://
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-
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #15 |
I also tried with kernel 5.8.0-050800rc5
In Linux Kernel Bug Tracker #208555, knotted10 (knotted10-linux-kernel-bugs) wrote : | #16 |
I can confirm, same thing is happening to me, using manjaro with kernel 5.6.19-2-MANJARO
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #17 |
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?).
In Linux Kernel Bug Tracker #208555, n0.b741n37+bugzilla.kernel (n0.b741n37+bugzilla.kernel-linux-kernel-bugs) wrote : | #18 |
+1 for this on Manjaro with kernel 5.7.14.
In Linux Kernel Bug Tracker #208555, contact (contact-linux-kernel-bugs) wrote : | #19 |
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #20 |
Is everyone experiencing this on machines other than the Lenovo Legion 7i? Or is everyone on this same machine so far?
In Linux Kernel Bug Tracker #208555, contact (contact-linux-kernel-bugs) wrote : | #21 |
Forgot to mentioned it, Legion 7i for me.
In Linux Kernel Bug Tracker #208555, vince.tavernier (vince.tavernier-linux-kernel-bugs) wrote : | #22 |
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.
In Linux Kernel Bug Tracker #208555, sentinum (sentinum-linux-kernel-bugs) wrote : | #23 |
I have the exact same issue on Linux version 5.4.0-47-generic (buildd@
In Linux Kernel Bug Tracker #208555, kernel.org (kernel.org-linux-kernel-bugs) wrote : | #24 |
(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://
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
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #25 |
(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://
>
> 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.
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #26 |
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #27 |
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #28 |
Created attachment 292497
Top half of top level audio level
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #29 |
Created attachment 292499
bottom half of the top level audio menu
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #30 |
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.
In Linux Kernel Bug Tracker #208555, kernel.org (kernel.org-linux-kernel-bugs) wrote : | #31 |
(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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #32 |
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.
In Linux Kernel Bug Tracker #208555, ealex95 (ealex95-linux-kernel-bugs) wrote : | #33 |
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://
I did not test the laptop with Windows yet, but I will try to do this soon.
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #34 |
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #35 |
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:/
>
> --- 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.
>
In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote : | #36 |
(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:/
> >
> > --- 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.
In Linux Kernel Bug Tracker #208555, ealex95 (ealex95-linux-kernel-bugs) wrote : | #37 |
> 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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #38 |
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.
In Linux Kernel Bug Tracker #208555, erkanadali91 (erkanadali91-linux-kernel-bugs) wrote : | #39 |
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.
In Linux Kernel Bug Tracker #208555, fodor18zoltan (fodor18zoltan-linux-kernel-bugs) wrote : | #40 |
I am also facing same issue on Ubuntu 20.04 with Legion 7i. Never worked on Linux.
Alsa info http://
Linux archy-Lenovo-
38 comments hidden Loading more comments | view all 879 comments |
3DRaven (3draven) wrote : | #1 |
- AlsaInfo.txt Edit (46.0 KiB, text/plain; charset="utf-8")
- CurrentDmesg.txt Edit (257.0 KiB, text/plain; charset="utf-8")
- Dependencies.txt Edit (2.2 KiB, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.5 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (290 bytes, text/plain; charset="utf-8")
- PulseList.txt Edit (49.8 KiB, text/plain; charset="utf-8")
Launchpad Janitor (janitor) wrote : | #2 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in alsa-driver (Ubuntu): | |
status: | New → Confirmed |
Przemek K. (azrael) wrote (last edit ): | #3 |
- legion7-ubuntu.txt Edit (74.6 KiB, text/plain)
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) wrote : | #4 |
This might be another case of https:/
summary: |
- [82N6, Realtek ALC287, Speaker, Internal] No sound at all + [Lenovo Legion7 82N6, Realtek ALC287, Speaker, Internal] No sound at all |
summary: |
- [Lenovo Legion7 82N6, Realtek ALC287, Speaker, Internal] No sound at all + [Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Speaker, Internal] No + sound at all |
Przemek K. (azrael) wrote : | #5 |
Alsa-info output: http://
Przemek K. (azrael) wrote : | #6 |
tags: | added: apport-collected impish |
Przemek K. (azrael) wrote : apport information | #7 |
ProblemType: Bug
ApportVersion: 2.20.11-0ubuntu70
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/
/dev/snd/pcmC1D0p: ubuntu 5091 F...m pulseaudio
/dev/snd/
CasperMD5CheckR
CasperVersion: 1.465
CurrentDesktop: ubuntu:GNOME
DistroRelease: Ubuntu 21.10
LiveMediaBuild: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012)
NonfreeKernelMo
Package: alsa-driver (not installed)
ProcEnviron:
TERM=xterm-
PATH=(custom, no user)
XDG_RUNTIME_
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSign
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.
dmi.board.name: LNVNB161216
dmi.board.vendor: LENOVO
dmi.board.version: SDK0R32862 WIN
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.
dmi.ec.
dmi.modalias: dmi:bvnLENOVO:
dmi.product.family: Legion 7 16ACHg6
dmi.product.name: 82N6
dmi.product.sku: LENOVO_
dmi.product.
dmi.sys.vendor: LENOVO
Przemek K. (azrael) wrote : AlsaInfo.txt | #8 |
Przemek K. (azrael) wrote : CurrentDmesg.txt | #9 |
Przemek K. (azrael) wrote : PaInfo.txt | #10 |
Przemek K. (azrael) wrote : ProcCpuinfoMinimal.txt | #11 |
Przemek K. (azrael) wrote : PulseList.txt | #12 |
Changed in sound-2.6: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
827 comments hidden Loading more comments | view all 879 comments |
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #840 |
Could you share your acpidump output?
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #841 |
(In reply to thornley.david from comment #819)
> I am running an 14IRP8 (Yoga Pro/Slim 9i), specifically this model
> (https:/
>
> 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-
> Also tried noble's firmware-sof-signed package, manually tweaking the amixer
> configuration.
>
> My alsa info ->
> https:/
>
> Thanks!!
Do you have full volume sound? I have a similar model (https:/
To get sound on linux 6.7 I had to update the firmware files and use `options snd-sof-
I didn't try a lot on 6.8 but my current config doesn't fix the bass there too.
In Linux Kernel Bug Tracker #208555, thornley.david (thornley.david-linux-kernel-bugs) wrote : | #842 |
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_
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.
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #843 |
Could someone please test if changing this fixup in the sound/pci/
[ALC287_
.type = HDA_FIXUP_FUNC,
.v.func = tas2781_fixup_i2c,
.chained = true,
.chain_id = ALC269_
},
to this:
[ALC287_
.type = HDA_FIXUP_FUNC,
.v.func = tas2781_fixup_i2c,
.chained = true,
.chain_id = ALC285_
},
It worked for ALC287_
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #844 |
(In reply to Gergo K from comment #826)
> Could someone please test if changing this fixup in the
> sound/pci/
>
> [ALC287_
> .type = HDA_FIXUP_FUNC,
> .v.func = tas2781_fixup_i2c,
> .chained = true,
> .chain_id = ALC269_
> },
>
> to this:
>
> [ALC287_
> .type = HDA_FIXUP_FUNC,
> .v.func = tas2781_fixup_i2c,
> .chained = true,
> .chain_id = ALC285_
> },
>
> It worked for ALC287_
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-
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #845 |
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.
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #846 |
(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://
Thank you for your attention!
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #847 |
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?
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #848 |
=(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://
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #849 |
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:/
>
> --- 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://
>
>
> 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.
>
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #850 |
(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:/
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #851 |
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:/
>
> --- 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:/
> to /usr/lib/firmware, so not sure if this affected something.
>
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #852 |
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?
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #853 |
Could you please comment out this line from patch_realtek.c and rebuild the kernel and start it without the module parameters?
SND_PCI_
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #854 |
(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_
> ALC287_
I will test it right now.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #855 |
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:/
>
> --- 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_
>> ALC287_
> I will test it right now.
>
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #856 |
(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_
> ALC287_
http://
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?
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #857 |
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_
!!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.
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #858 |
(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_
> SSID before the Codec SSID in the same table. So it picks the
> ALC287_
>
>
> !!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
In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote : | #859 |
(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_
> SSID before the Codec SSID in the same table. So it picks the
> ALC287_
>
>
> !!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)
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #860 |
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_
https:/
And I sent a question about how to handle this collision:
https:/
If you are interested in linux sound development, you can subscribe to the linux-sound list:
http://
In Linux Kernel Bug Tracker #208555, thornley.david (thornley.david-linux-kernel-bugs) wrote : | #861 |
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:/
Applied the latest firmware to /lib/firmware from https:/
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. :)
In Linux Kernel Bug Tracker #208555, thornley.david (thornley.david-linux-kernel-bugs) wrote : | #862 |
FYI, this looks to have been improved in Ubuntu's 6.8.1 mainline (https:/
Giulio Iannelli (opisthofulax) wrote : | #863 |
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.
In Linux Kernel Bug Tracker #208555, thornley.david (thornley.david-linux-kernel-bugs) wrote : | #864 |
FYI, broken again in 6.8.4, 6.8.3 (not sure about 6.8.2).
In Linux Kernel Bug Tracker #208555, hyc (hyc-linux-kernel-bugs) wrote : | #865 |
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.
In Linux Kernel Bug Tracker #208555, dlinuigh (dlinuigh-linux-kernel-bugs) wrote : | #866 |
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.
In Linux Kernel Bug Tracker #208555, thornley.david (thornley.david-linux-kernel-bugs) wrote : | #867 |
Working fine again for me in 6.8.5 :) Sorry for the spam!
In Linux Kernel Bug Tracker #208555, tuupic (tuupic-linux-kernel-bugs) wrote : | #868 |
(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.
In Linux Kernel Bug Tracker #208555, admin (admin-linux-kernel-bugs) wrote : | #869 |
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...
In Linux Kernel Bug Tracker #208555, tuupic (tuupic-linux-kernel-bugs) wrote : | #870 |
(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 ?
In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote : | #871 |
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.
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #872 |
(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.
In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote : | #873 |
Created attachment 306161
attachment-
> ...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?
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #874 |
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:
af5adf85ef96839
951a483a58b1b41
f7f319ba68ab37e
dfb907ce0135030
a7ebbd19c73cd6f
f1f048656902031
b796beae38a02fa
830cf65b0d6e235
2a4d57199bc04eb
fcaa167bb712cbe
9a6089a79ef6038
0ace13d455c64d5
a90c1c801076cf6
3723cbf4848c3df
dfb907ce0135030
a7ebbd19c73cd6f
33c27f3eec9e46e
4824e06b5919b57
61dcfeb8c3dd4c5
38f473162f7dd35
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:/
>
> --- 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?
>
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #875 |
The firmware files have not changed.
I think it's possible that this commit is the culprit:
https:/
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,
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
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #876 |
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.
In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote : | #877 |
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>/
In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote : | #878 |
On 4/16/24 16:54, <email address hidden> wrote:
> https:/
>
> --- 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...
In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote : | #879 |
> Please try the following and report if it fixes the issue:
> amixer -c 1 cset numid=3,
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,
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.
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=ba86fe76a9d9 cf1cced56600edf 82eb206a36a72
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.