Bug #1958019 “[Lenovo Legion7 16ACHg6 82N6, Realtek ALC287, Spea...” : Bugs : alsa-driver package : Ubuntu

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-07-14:

#13

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.

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-07-18:

#14

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.

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-07-18:

#15

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, knotted10 (knotted10-linux-kernel-bugs) wrote on 2020-07-30:

#16

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-08-07:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, n0.b741n37+bugzilla.kernel (n0.b741n37+bugzilla.kernel-linux-kernel-bugs) wrote on 2020-08-20:

#18

+1 for this on Manjaro with kernel 5.7.14.

Revision history for this message

In Linux Kernel Bug Tracker #208555, contact (contact-linux-kernel-bugs) wrote on 2020-08-31:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-08-31:

#20

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, contact (contact-linux-kernel-bugs) wrote on 2020-08-31:

#21

Forgot to mentioned it, Legion 7i for me.

Revision history for this message

In Linux Kernel Bug Tracker #208555, vince.tavernier (vince.tavernier-linux-kernel-bugs) wrote on 2020-08-31:

#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.fc32.x86_64.

Revision history for this message

In Linux Kernel Bug Tracker #208555, sentinum (sentinum-linux-kernel-bugs) wrote on 2020-09-09:

#23

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.

Revision history for this message

In Linux Kernel Bug Tracker #208555, kernel.org (kernel.org-linux-kernel-bugs) wrote on 2020-09-13:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-09-13:

#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://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.

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-09-13:

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

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-13:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-13:

#28

Created attachment 292497
Top half of top level audio level

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-13:

#29

Created attachment 292499
bottom half of the top level audio menu

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-14:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, kernel.org (kernel.org-linux-kernel-bugs) wrote on 2020-09-14:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-14:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, ealex95 (ealex95-linux-kernel-bugs) wrote on 2020-09-24:

#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://alsa-project.org/db/?f=60beb004225ca38c49bb6a1495e6cd713a1a4f1e

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-09-26:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-26:

#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://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.
>

Revision history for this message

In Linux Kernel Bug Tracker #208555, pyronavi (pyronavi-linux-kernel-bugs) wrote on 2020-09-26:

#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://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.

Revision history for this message

In Linux Kernel Bug Tracker #208555, ealex95 (ealex95-linux-kernel-bugs) wrote on 2020-09-26:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2020-09-26:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, erkanadali91 (erkanadali91-linux-kernel-bugs) wrote on 2020-10-13:

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, fodor18zoltan (fodor18zoltan-linux-kernel-bugs) wrote on 2020-10-30:

#40

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

Revision history for this message

3DRaven (3draven) wrote on 2022-01-15:

#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")

Revision history for this message

Launchpad Janitor (janitor) wrote on 2022-01-16:

#2

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

Changed in alsa-driver (Ubuntu):
status:	New → Confirmed

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16 (last edit on 2022-01-16):

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

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16:

#4

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

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

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16:

#5

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

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16:

#6

alsa-info-legion7.txt Edit (47.3 KiB, text/plain)

Alsa-info output saved to a file

tags:

added: apport-collected impish

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: apport information

#7

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

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: AlsaInfo.txt

#8

AlsaInfo.txt Edit (44.9 KiB, text/plain)

apport information

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: CurrentDmesg.txt

#9

CurrentDmesg.txt Edit (98.4 KiB, text/plain)

apport information

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: PaInfo.txt

#10

PaInfo.txt Edit (91.7 KiB, text/plain)

apport information

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: ProcCpuinfoMinimal.txt

#11

ProcCpuinfoMinimal.txt Edit (1.5 KiB, text/plain)

apport information

Revision history for this message

Przemek K. (azrael) wrote on 2022-01-16: PulseList.txt

#12

PulseList.txt Edit (27.5 KiB, text/plain)

apport information

Bug Watch Updater (bug-watch-updater) on 2022-01-16

Changed in sound-2.6:
importance:	Unknown → Medium
status:	Unknown → Confirmed

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2024-04-17:

#878

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote on 2024-04-17:

#879

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, kernel (kernel-linux-kernel-bugs) wrote on 2024-04-17:

#880

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote on 2024-04-18:

#881

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote on 2024-04-18:

#882

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`

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`

Revision history for this message

In Linux Kernel Bug Tracker #208555, soyer (soyer-linux-kernel-bugs) wrote on 2024-04-19:

#883

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote on 2024-04-19:

#884

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, dreamsyntax (dreamsyntax-linux-kernel-bugs) wrote on 2024-04-19:

#885

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2024-04-20:

#886

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, shenghao-ding (shenghao-ding-linux-kernel-bugs) wrote on 2024-04-22:

#887

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2024-04-22:

#888

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
>

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2024-04-22:

#889

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, shenghao-ding (shenghao-ding-linux-kernel-bugs) wrote on 2024-04-23:

#890

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

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

Revision history for this message

In Linux Kernel Bug Tracker #208555, shenghao-ding (shenghao-ding-linux-kernel-bugs) wrote on 2024-04-23:

#891

(In reply to dreamsyntax from comment #867)
> While audio working, and content is playing > 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 > 00: 00 00 00 28 21 41 00 20 09 02 2a 28 10 93 02 00 > 10: 84 00 00 08 0a 00 44 80 00 8d 00 62 36 40 00 01 > 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 > 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 (actively outputting to device)
0123456789abcdef
...(!A. ??*(???.
?..??.D?.?.b6@.?
.?..............
....????...???..
??.??....????.\.
.??<??????.????.
!?<H???.???c.??.
??.?.?..?. .?.%.
................
................
................
................
................
................
................
................

Kindly follow Comment 872 to force tas2781 to work

Revision history for this message

In Linux Kernel Bug Tracker #208555, shenghao-ding (shenghao-ding-linux-kernel-bugs) wrote on 2024-04-23:

#892

# . tas2781-2dev-on.sh 2

Revision history for this message

In Linux Kernel Bug Tracker #208555, cam (cam-linux-kernel-bugs) wrote on 2024-04-25:

#893

Download full text (3.3 KiB)

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