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

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.

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.

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

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

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?).

+1 for this on Manjaro with kernel 5.7.14.

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.

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

Forgot to mentioned it, Legion 7i for me.

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.

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.

(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

(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.

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

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.

Created attachment 292497
Top half of top level audio level

Created attachment 292499
bottom half of the top level audio menu

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 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.

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.

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.

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.

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.
>

(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.

> 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.

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.

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.

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

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

(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.

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 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 ?

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 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.

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?

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?
>

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

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.

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>/

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...

> 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.

(In reply to Gergo K from comment #857)
> 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

Hi, I had this issue for some time but thought it was because of bad setup in my part. This command seems to fix the issue without having to rewake the laptop. I'm testing your patch and will report back soon.

Hi,

> there are a lot of entries, what exactly am I looking for?

Find the card with 'Speaker Force Firmware Load' control, then change the -c and numid parameters accordingly.

> What is the expected result of the above?

It reloads the program of the amplifiers before powering up the amplifiers. (amplifiers (software) shutdown occurs after 3 idle seconds)
If you set it to 0, the program will only be reloaded after module init and after wakeup/rewake.

you can check the value of the control with:
amixer -c 1 cget numid=3,name='Speaker Force Firmware Load'

Before bec7760a6c5fa59593dac264fa0c628e46815986 ("ALSA: hda/tas2781: do not reset cur_* values in runtime_suspend"), the driver reloaded the program and configuration every time, and this control wasn't effective.
Reloading the program and config takes 0.3 second or more, that's why I wanted to remove that behavior. It's annoying to wait every time you start anything.

I can only guess what could be wrong with tas2781 setups. Probably the amps will go into failure state or reset state after a while.

It would help if someone dumps the registers as root, when the amplifiers are not working:

rmmod snd_hda_scodec_tas2781_i2c
i2cset -y 3 0x70 0x00 0x00
i2cset -y 3 0x70 0x7f 0x00
i2cdump -y 3 0x70
modprobe snd_hda_scodec_tas2781_i2c

first line unloads the module
second line changes the page to 0x00
third line changes the book to 0x00
fourth line dumps the page
fifth line loads the module

The bus number (3) may be different.
The address of the second amplifier is 0x72.

Here is the data sheet, if anyone wants to dig :)
https://www.ti.com/lit/ds/symlink/tas2781.pdf

A few things since I last posted:

After having done the below command...
`amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1`
Every subsequent reboot the audio never broke. I had multiple 2+ hour
sessions with no issue.
I never re-ran the above command.
Adjusting the volume would have a noticeable 'delay' (around 0.5
seconds to 3 seconds) before the audio mixer related GUI would
respond.

As a test I did a fresh install of endeavour-os (on kernel 6.8.7) and
sure enough, the issue is back and I can break the audio in less than
5 minutes of use.

> It would help if someone dumps the registers as root, when the amplifiers are
not working

Unfortunately, the result of the below command are as follows once audio breaks:
$ su root
# rmmod snd_hda_scodec_tas2781_i2c
# i2cset -y 3 0x70 0x00 0x00
Error: Write failed
# i2cset -y 3 0x70 0x00 0x00
Error: Write failed
# i2cset -y 3 0x70 0x7f 0x00
Error: Write failed
# i2cdump -y 3 0x70
No size specified (using byte-data access)
    0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
10: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
20: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
30: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
40: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
50: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
60: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
70: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
80: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
90: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
a0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
b0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
c0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
d0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
e0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX
f0: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XXXXXXXXXXXXXXXX

After modprobe snd_hda_scodec_tas2781_i2c is run, audio actually works
again, for a few minutes.

I will note I get the same result above even if I do it while audio
works, so if I'm doing something wrong please let me know.

For testing purposes, if I want to enable/disable your workaround
solution, would changing the 1 at the end to 0 be sufficient?
`amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 1` ->
`amixer -c 1 cset numid=3,name='Speaker Force Firmware Load' 0`

> I never re-ran the above command.

The alsactl restores all audo controls after boot, including this one.

> Unfortunately, the result of the below command are as follows once audio
> breaks:

Please try 0x38 instead of 0x70, and if still not found, try 0,1,2,4 instead of bus 3.

If you still not found, please send your acpidump output.

> For testing purposes, if I want to enable/disable your workaround
solution, would changing the 1 at the end to 0 be sufficient?

Yes, setting it to 0 disables always reloading.

(In reply to Gergo K from comment #865)
> Please try 0x38 instead of 0x70, and if still not found, try 0,1,2,4 instead
> of bus 3.
>
> If you still not found, please send your acpidump output.

# i2cset -y 1 0x38 0x7f 0x00
Error: Write failed
# i2cset -y 2 0x38 0x7f 0x00
# i2cset -y 2 0x38 0x00 0x00
# i2cset -y 2 0x38 0x7f 0x00
# i2cdump -y 2 0x38
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 02 28 21 41 00 20 09 02 2a 28 10 93 02 00 ..?(!A. ??*(???.
10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.?
20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?..............
30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???..
40: f6 14 00 00 80 80 00 00 00 00 02 99 80 00 1c 00 ??..??....???.?.
50: 00 00 a2 78 85 13 78 ff c7 c8 40 88 d9 81 00 00 ..?x??x.??@???..
60: 21 08 3c 48 84 88 b2 00 04 09 12 7b 00 1a 03 00 !?<H???.???{.??.
70: 96 02 00 08 00 e0 00 00 00 00 20 00 a0 00 74 00 ??.?.?.... .?.t.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Above is after the sound is broken.

Immediately after doing the above, where sound is working, and then re-dump
# modprobe snd_hda_scodec_tas2781_i2c
# rmmod snd_hda_scodec_tas2781_i2c
# i2cset -y 2 0x38 0x00 0x00
# i2cset -y 2 0x38 0x7f 0x00
# i2cdump -y 2 0x38

Results in the exact same output.

While audio working, and content is playing (actively outputting to device)
Output is different:
i2cset -y 2 0x38 0x00 0x00
i2cset -y 2 0x38 0x7f 0x00
i2cdump -y 2 0x38
No size specified (using byte-data access)
     0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: 00 00 00 28 21 41 00 20 09 02 2a 28 10 93 02 00 ...(!A. ??*(???.
10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.?
20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?..............
30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???..
40: f6 14 00 02 19 00 00 00 00 04 02 19 80 00 5c 00 ??.??....????.\.
50: 00 06 a3 3c 85 08 81 da 87 84 00 97 d9 81 01 00 .??<??????.????.
60: 21 08 3c 48 84 88 b2 00 04 09 12 63 00 1a 03 00 !?<H???.???c.??.
70: 96 02 00 08 00 e0 00 00 0f 00 20 00 a0 00 25 00 ??.?.?..?. .?.%.
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Unfortunately, my sound finally did fail again... But the symptoms seem different. Audacious just hangs for a while before ultimately giving up (and it stops hanging and stops trying to play).

But this is a new type of failure so perhaps this patch did make a bit of a difference?
https://bugzilla.kernel.org/show_bug.cgi?id=208555#c863

But this happened immediately after resuming from suspend. My laptop went to sleep with mute enabled, I started playing sound after resuming, noticed I was muted, and resumed... And sound was no longer working.

Could bec7760a6c5fa59593dac264fa0c628e46815986 be the issue?

This did not fixed my count:
amixer -c 0 cset numid=3,name='Speaker Force Firmware Load' 1

(-c 1 is incorrect for my laptop.)

kindly run
#i2cdetect -r 2
and run following command during no sound issue
dmesg -c > kernel-mute.log

To confirm... You want my dmesg output when there's no issue, but you
want me to clear it after reading it?

On 4/22/24 03:23, <email address hidden> wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> Tintin (<email address hidden>) changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |<email address hidden>
>
> --- Comment #869 from Tintin (<email address hidden>) ---
> kindly run
> #i2cdetect -r 2
> and run following command during no sound issue
> dmesg -c > kernel-mute.log
>

(In reply to Tintin from comment #869)
> kindly run
> #i2cdetect -r 2
> and run following command during no sound issue
> dmesg -c > kernel-mute.log

Forgot to get the dmesg even though I did look at the dmesg output (*facepalm*). There are no messages related to this in dmesg when this occurs. But next time it happens, I'll get this to you to be thorough and Just In Case.

i2cdetect -r 2
# When it's working:
i2cdetect -y -r 2
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

# When it's not working:
i2cdetect -y -r 2
     0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- 3f
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

I tried on i2cbus 0 and 1, no changes there either.

This time I finally remembered to try hibernating (suspend to disk). Resuming didn't fix the issue.

Save following as tas2781-2dev-on.sh
run ". tas2781-2dev-on.sh" in root mode during no sound, and check whether to work?
################Start###################
#!/bin/sh
# echo Turn on log!
# set -x
clear
function clear_stdin()
(
    old_tty_settings=`stty -g`
    stty -icanon min 0 time 0

    while read none; do :; done

    stty "$old_tty_settings"
)

if [ $# -ne 1 ];
then
 echo Kindly specify the i2c bus number. The default i2c bus number is 3.
 echo Command as following:
 echo $0 i2c-bus-number
 i2c_bus=3
else
 i2c_bus=$1
fi

echo i2c bus is $i2c_bus
i2c_addr=(0x3f 0x38)

count=0
for value in ${i2c_addr[@]};
do
val=$((${count} % 2))
i2cset -f -y $i2c_bus $value 0x00 0x00
i2cset -f -y $i2c_bus $value 0x7f 0x00
i2cset -f -y $i2c_bus $value 0x01 0x01
i2cset -f -y $i2c_bus $value 0x0e 0xc4
i2cset -f -y $i2c_bus $value 0x0f 0x40
i2cset -f -y $i2c_bus $value 0x5c 0xd9
i2cset -f -y $i2c_bus $value 0x60 0x10
if [ $val -eq 0 ];
then
 i2cset -f -y $i2c_bus $value 0x0a 0x1e
else
 i2cset -f -y $i2c_bus $value 0x0a 0x2e
fi
i2cset -f -y $i2c_bus $value 0x0d 0x01
i2cset -f -y $i2c_bus $value 0x16 0x40
i2cset -f -y $i2c_bus $value 0x00 0x01
i2cset -f -y $i2c_bus $value 0x17 0xc8
i2cset -f -y $i2c_bus $value 0x00 0x04
i2cset -f -y $i2c_bus $value 0x30 0x00
i2cset -f -y $i2c_bus $value 0x31 0x00
i2cset -f -y $i2c_bus $value 0x32 0x00
i2cset -f -y $i2c_bus $value 0x33 0x01

i2cset -f -y $i2c_bus $value 0x00 0x08
i2cset -f -y $i2c_bus $value 0x18 0x00
i2cset -f -y $i2c_bus $value 0x19 0x00
i2cset -f -y $i2c_bus $value 0x1a 0x00
i2cset -f -y $i2c_bus $value 0x1b 0x00
i2cset -f -y $i2c_bus $value 0x28 0x40
i2cset -f -y $i2c_bus $value 0x29 0x00
i2cset -f -y $i2c_bus $value 0x2a 0x00
i2cset -f -y $i2c_bus $value 0x2b 0x00

i2cset -f -y $i2c_bus $value 0x00 0x0a
i2cset -f -y $i2c_bus $value 0x48 0x00
i2cset -f -y $i2c_bus $value 0x49 0x00
i2cset -f -y $i2c_bus $value 0x4a 0x00
i2cset -f -y $i2c_bus $value 0x4b 0x00
i2cset -f -y $i2c_bus $value 0x58 0x40
i2cset -f -y $i2c_bus $value 0x59 0x00
i2cset -f -y $i2c_bus $value 0x5a 0x00
i2cset -f -y $i2c_bus $value 0x5b 0x00

i2cset -f -y $i2c_bus $value 0x00 0x00
i2cset -f -y $i2c_bus $value 0x02 0x00
count=$((${count} + 1))
done;
clear_stdin
################End###################

(In reply to dreamsyntax from comment #867)
> While audio working, and content is playing (actively outputting to device)
> Output is different:
> i2cset -y 2 0x38 0x00 0x00
> i2cset -y 2 0x38 0x7f 0x00
> i2cdump -y 2 0x38
> No size specified (using byte-data access)
> 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
> 00: 00 00 00 28 21 41 00 20 09 02 2a 28 10 93 02 00 ...(!A. ??*(???.
> 10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 ?..??.D?.?.b6@.?
> 20: 2e 14 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .?..............
> 30: 00 00 00 00 06 bd ad a8 00 00 00 fc bb dd ff ff ....????...???..
> 40: f6 14 00 02 19 00 00 00 00 04 02 19 80 00 5c 00 ??.??....????.\.
> 50: 00 06 a3 3c 85 08 81 da 87 84 00 97 d9 81 01 00 .??<??????.????.
> 60: 21 08 3c 48 84 88 b2 00 04 09 12 63 00 1a 03 00 !?<H???.???c.??.
> 70: 96 02 00 08 00 e0 00 00 0f 00 20 00 a0 00 25 00 ??.?.?..?. .?.%.
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Kindly follow Comment 872 to force tas2781 to work

# . tas2781-2dev-on.sh 2

Created attachment 306213
kernel-mute.log

(In reply to Tintin from comment #874)
> # . tas2781-2dev-on.sh 2

Sorry if this is a bit long, but trying to include info to help debug the issue.

Well, it has finally happened again... It seems like the script hasn't really helped... But I'll have to try it again next time this happens to determine what, if any, role it had. So far it looks like it hasn't helped.

I was able to get my sound working by running this: "killall pipewire-pulse" and quitting/killing audacious (audacious usually but not always hangs when this starts happening), and quitting firefox, thought not necessarily in that order?

But even that isn't enough to completely fix it. Likely, it would come back as soon as I start playing audio from more than one application at a time.

When playing audio from another application, it would work for a few seconds, and then one of the applications would stop working. Almost like the audio device had become usable by one application at a time (like in the early ALSA days prior to pulseaudio becoming common). And probably if I stopped the other application, it usually wouldn't stop working again until repeating the above steps.

But playing with it some more (with both quitting applications, killing pipewire-pulse over and over), I was eventually able to get audio to consistently work again (ie, normally) for about the last 30 minutes or so.

I tried logging out and back at one point... That didn't seem to fix it either. It wasn't until several (or a bunch more) killing pipewire-pulse, restarting firefox and audacious a few times (I could try other software too!) that it started working again.

I'm leaning toward this being a pipewire-pulse issue at this point... but it's possible that there's a driver issue that causes pipewise-pulse becoming wedged, and that running tas2781-2dev-on.sh and killing pipewise-pulse I'm eventually able to get things into a good state.

If this happens again, I will conduct more testing... And I say if, because I think Ubuntu 24.04 is out today, and if it is... I will likely upgrade. If this is a software issue, good chance 24.04 won't have this problem. I'll report back with my results either way.

Anyone else tried killing pipewire-pulse when having issues?

I didn't see any sort of run away processes, I simply did "ps paux | grep pulse" and that was the only process that showed up so I tried killing it. It was just a guess from remembering all the early pulseaudio issues from over a decade ago. :D

Here's my info for convenience:
Kernel 6.8.7
Kubuntu 23.10
Running with KDE+Wayland

My pipewire-pulse info:

apt policy pipewire-pulse
pipewire-pulse:
  Installed: 0.3.79-2
  Candidate: 0.3.79-2
  Version table:
 *** 0.3.79-2 500
        500 http://us.archive.ubuntu.com/ubuntu mantic/main amd64 Packages
        100 /var/lib/dpkg/status

I didn't have this problem with the older kernel 6.7.x series, but maybe there was a pipewire-pulse update that happened? Or and update to a package it depends on?

Finally, I've attached the requested dmesg output. My audio problems started after 10:30 (maybe around 10:40-ish?) and my audio had been completely working for around...

> Kindly follow Comment 872 to force tas2781 to work

I had been using 6.7.9 for the last week with no issues.
I upgrade to 6.8.7, and within 3 minutes audio broken.

I save your script and run it
-- su root
-- ./tas2781-2dev-on.sh

Sound works again, however:
- sound is notably louder compared to 6.7.9
- right inside / right speaker? (not sure if there's 1 or 2) is louder than on 6.8.7 with your script.

After a few minutes, once again audio will break again, until I re-run your script.
Interestingly, after second run of script the audio balance is fixed. Both left/right speakers sound correct instead of being right-side balanced.

Unfortunately, breaks soon after.

For me audio never lasts more than ~3min.

I also notice that the audio levels will oscillate occasionally on 6.8.x kernels, where this does not occur on 6.7.9.

If there is anything more I can do to help, please advise. I can try any combination of kernel/patches if needed. I just want to resolve this issue without beings stuck on 6.7.9 kernel.

Again for my posts, model is:
Lenovo Legion Pro 7i (Gen 8, 2023) - and alsamixer shows ALC287 under system info.

Created attachment 306214
attachment-10825-0.html

I am currently out of the office on holiday I will be returning on Tuesday April 30th, I will not be checking email.

In my case, there seems to be an issue with pipewire using too many file descriptors:
systemctl status --user pipewire
● pipewire.service - PipeWire Multimedia Service
     Loaded: loaded (/usr/lib/systemd/user/pipewire.service; enabled; preset: enabled)
     Active: active (running) since Fri 2024-04-26 07:53:43 PDT; 11h ago
TriggeredBy: ● pipewire.socket
   Main PID: 3468 (pipewire)
      Tasks: 3 (limit: 38161)
     Memory: 12.6M
        CPU: 38.400s
     CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/pipewire.service
             └─3468 /usr/bin/pipewire

Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x60925302fed0: error seq:13 -9 (set_activation: Bad file descriptor)
Apr 26 18:53:58 hostname pipewire[3468]: pw.core: 0x609252c77940: error -9 for resource 2: node_set_io failed: Bad file descriptor
Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x60925302fed0: error seq:14 -9 (node_set_io failed: Bad file descriptor)
Apr 26 18:53:58 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:1021 Too many open files
Apr 26 18:53:58 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:1020 Too many open files
Apr 26 18:53:58 hostname pipewire[3468]: pw.core: 0x609252c77940: error -9 for resource 2: set_activation: Bad file descriptor
Apr 26 18:53:58 hostname pipewire[3468]: mod.client-node: 0x609252d7cdf0: error seq:23 -9 (set_activation: Bad file descriptor)
Apr 26 18:54:06 hostname pipewire[3468]: mod.protocol-native: connection 0x609252e5f710: can't DUP fd:579 Too many open files
Apr 26 18:58:00 hostname pipewire[3468]: mod.client-node: 0x609252fc1b70: unknown peer 0x609252fc2050 fd:98
Apr 26 18:58:15 hostname pipewire[3468]: mod.protocol-native: 0x609252c9c030: connection_data: client 0x609252fc29c0 error -71 (Protocol error)

I was able to get my sound working by logging out and back in.

After I got it working, I ran this:
lsof -p3468 | wc -l
1013

I wonder if it was around 1024 before I logged out..?

The open file limit for the process is: 1024

This explains why "killall pipewire-pulse" would get my sound working again for a single application... It was freeing up one file descriptor.

Is this a pipewire bug, a tas2781 driver bug, or a bit of both? I think if this were a general pipewire issue, we'd be hearing a lot more complaints...

After logging in, I tried this:
systemctl restart --user pipewire

This resulted in a new pipewire process and only 25 open file descriptors. Wonder if this would have fixed the issue without logging out? Something else to try next time.

Next time this happens, I'll see if I can figure what all the file descriptors are for.

For others having this or similar trouble, see if you're having similar issues with pipewire (or perhaps even pulse) and file descriptors.

/var/log/syslog is another valid place to check for these messages (at least on Ubuntu).

(In reply to Cameron Berkenpas from comment #749)
> See https://bugzilla.kernel.org/show_bug.cgi?id=216194 for a new patch.
> Currently the latest is lenovo-7i-gen7-sound-6.2.0-rc3-0.0.5b-002.patch
>
> This latest patch theoretically has support for Blake Lee's machine.
>
> A new revision of the 16IAX7.
>
> oppsig's Yoga Slim 7 Carbon 14ACN6
>
> Pierre Hébert,
>
> I missed that you were getting this error previous: "Serial bus multi
> instantiate pseudo device driver CSC3551:00: error -ENOENT: Error requesting
> irq at index 0"
>
> That is indeed occurring before any of my code. Some hopefully good news is
> that this is a Cirrus Logic issue that they might fix if you can report it
> to them. Once fixed, you'd probably still need a patch such as mine to get
> you over the finish line.
>
> PLEASE READ MY COMMENT HERE AS THIS PATCH IS USE AT-YOUR-OWN-RISK:
> https://bugzilla.kernel.org/show_bug.cgi?id=216194#c66
>
> From here on out, I will direct people to bug
> https://bugzilla.kernel.org/show_bug.cgi?id=216194 as there's far too many
> posts in this thread and it's made things difficult to keep track of.

Hey all, I'm on the Lenovo Legion Slim 7 Gen 7 AMD version from 2022, and all of a sudden, after upgrading my Fedora install to 6.8.6-200.fc39.x86_64 my audio works! Not sure what happened on that front, but figured I'd stop back in and update.

After continued use of 6.8.7 and later 6.8.8, I can confirm using the
`./tas2781-2dev-on.sh 2` in my case as root regularly whenever audio goes out works fine.

What needs to happen at the kernel level / in a patch to resolve this?

I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire version is:
Compiled with libpipewire 1.0.5
Linked with libpipewire 1.0.5

Regards

(In reply to Markus from comment #881)
> I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation
> of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing
> i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire
> version is:
> Compiled with libpipewire 1.0.5
> Linked with libpipewire 1.0.5
>
> Regards

That script is for TI 2781 smart samps. The 16IAH7 has Cirrus logic, so the script definitely won't work there.

(In reply to Markus from comment #881)
> I tested this script on my Lenovo Legion S7 16IAH7 with a fresh installation
> of Fedora Linux 40 with Kernel 6.8.8-300.fc40.x86_64. After installing
> i2c-tools the script return a lot of "Error: Write failed" errors. Pipewire
> version is:
> Compiled with libpipewire 1.0.5
> Linked with libpipewire 1.0.5
>
> Regards

https://patchwork.kernel.org/project/alsa-devel/list/?submitter=212831

Please try this patchset, that works for Lenovo Legion S7 16IAH7. I got sound myself for the first time a couple of days ago with it (tested on 6.8.7). although the volume is quite low (I cannot compare with windows, never ran it), it seems to work flawlessly.
The missing part is really tiny, maybe this will land in mainline soon.

Regards.

Related:
https://bugzilla.suse.com/show_bug.cgi?id=1223462
https://github.com/torvalds/linux/commit/39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f

Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus.

Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023)

The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it usually every time media stops outputting to the audio out.

Created attachment 306307
attachment-8402-0.html

I am currently out of the office on holiday I will be returning on Tuesday May 28th, I will not be checking email.

(In reply to dreamsyntax from comment #884)
> Related:
> https://bugzilla.suse.com/show_bug.cgi?id=1223462
> https://github.com/torvalds/linux/commit/
> 39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f
>
> Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus.
>
> Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the
> same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023)
>
> The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it
> usually every time media stops outputting to the audio out.

Are you the one that filed this bug?
https://bugzilla.suse.com/show_bug.cgi?id=1223462

If that's not you, did you try the workaround in that ticket?

If so, you have the 16ARX8H, and it sounds like there's an overlap with a laptop with the same ID that uses Cirrus Logic instead of TI.

I looked through the thread and didn't see a link to your alsa-info. Did you share it and I just missed it in this very long thread? :D

> If that's not you, did you try the workaround in that ticket?

Hi, that is not me, my handle is same across bug reports. That
computer has a Cirrus Logic. Mine has TI.
For that model 6.7.9 is the kernel that broke support.
For me 6.7.9 is the last *working* kernel. Everything after it -
6.8.0+ has audio stopping unless re-running TAS script periodically
after media source stops.

I think there is a lot of confusion because of the same PCI SSID
despite using Cirrus Logic or TI TAS2781.

My laptop is "Legion Pro 7 16IRX8H / 82QW" - its the Gen 8 2023 model
with Intel CPU and NVIDIA GPU.
This laptop has the TI TAS2781.

This is not the same as Gen 7 nor the Gen 8 'Slim 7i' - which has Cirrus.

---
Regarding alsa-info:
https://alsa-project.org/db/?f=bca5f20c2e21730fb686902076414069c94295e6

On Sat, May 18, 2024 at 9:57 PM <email address hidden> wrote:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=208555
>
> --- Comment #886 from Cameron Berkenpas (<email address hidden>) ---
> (In reply to dreamsyntax from comment #884)
> > Related:
> > https://bugzilla.suse.com/show_bug.cgi?id=1223462
> > https://github.com/torvalds/linux/commit/
> > 39815cdfc8d46ce2c72cbf2aa3d991c4bfb0024f
> >
> > Now with Kernel 6.9.0 the issue should be fixed for devices with Cirrus.
> >
> > Unfortunately for me on TI TAS2781 kernel 6.9.0 and 6.9.1 still have the
> > same behavior as all kernels after 6.7.9. (Lenovo Legion Pro 7i Gen 8 2023)
> >
> > The `./tas2781-2dev-on.sh 2` has been my workaround, having to run it
> > usually every time media stops outputting to the audio out.
>
> Are you the one that filed this bug?
> https://bugzilla.suse.com/show_bug.cgi?id=1223462
>
> If that's not you, did you try the workaround in that ticket?
>
> If so, you have the 16ARX8H, and it sounds like there's an overlap with a
> laptop with the same ID that uses Cirrus Logic instead of TI.
>
> I looked through the thread and didn't see a link to your alsa-info. Did you
> share it and I just missed it in this very long thread? :D
>
> --
> You may reply to this email to add a comment.
>
> You are receiving this mail because:
> You are on the CC list for the bug.

Forgot to mention, yes I've also created this modprobe file. per
https://bugzilla.suse.com/show_bug.cgi?id=1223462
It caused system crash initially (for some reason), but in reboots
after, asound would work on startup until media plays / stops playing
- then it would be back in broken state again. So a slight improvement
I guess?