Bug 1226449

Summary:	Intermittent sound Lenovo Legion Pro 7 16ARX8H
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Brynn Dunlop <brynn>
Component:	Sound	Assignee:	Takashi Iwai <tiwai>
Status:	NEW ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	brynn
Version:	Current	Flags:	tiwai: needinfo? (brynn)
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE Tumbleweed
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	alsa -info.sh With no sound also-info.sh With sound

Description Brynn Dunlop 2024-06-17 19:26:53 UTC

Created attachment 875531 [details]
alsa -info.sh With no sound

I have intermittent sound from my speakers. Ive had this on a couple of forums for a while to try gather more info but no luck.

The quirks have only recently been added to allow the speakers to work and they do but they stop after a few minutes if i open another window or click a notification.

However, if i open a video in vlc before they have stopped it will play fine for half an hour.

When they have stopped I can bring it back by setting my laptop to sleep and waking it up again the immediately playing something

They have stopped in the time its taken to type this out.

I’ve attached alsa-info.sh with the sound working and one without from the same boot a few minutes apart.

To work around this i can play a long audio file on loop with the volume set to 0.

This is somewhat related to Bug 1223462. I never noticed this being an issue with 6.7.9-1-default but don't have it any more and its too far back in the repo history for me to download.

Thanks brynn.

Comment 1 Brynn Dunlop 2024-06-17 19:27:48 UTC

Created attachment 875532 [details]
also-info.sh With sound

Comment 2 Takashi Iwai 2024-06-18 11:14:14 UTC

This sounds like an issue with the runtime PM.

Is it only about the speaker output?  That is, does the headphone output suffer from the same problem, or does it keep working?

Comment 3 Brynn Dunlop 2024-06-30 13:40:42 UTC

Headphones are fine still, its just the speaker output that stops.

Comment 4 Takashi Iwai 2024-07-09 14:09:23 UTC

Try to set power_save=0 option for snd-hda-intel.  e.g. create a *.conf file in /etc/modprobe.d/ containing the following line

options snd-hda-intel power_save=0

And try reboot / retest.  Check the content of /sys/module/snd_hda_intel/parameters/power_save whether it's kept 0.  Some system daemon (like power tuning stuff) may turn this on/off automatically, too.

Note that, if even the above helps, it's merely a workaround.  But it'd good to know if this prevents the issue.

Comment 5 Brynn Dunlop 2024-07-20 12:00:11 UTC

So passing the option snd-hda-intel power_save=0
doesn't have any effect on the value in /sys/module/snd_hda_intel/parameters/power_save.

As I have read on the forums this hasn't had an effect since the release of Leap 15.5. I'm not sure how much relevance that has to Tumbleweed though.

Editing the value in /sys/module/snd_hda_intel/parameters/power_save with 

"echo 0 > /sys/module/snd_hda_intel/parameters/power_save" 

as root works and it mostly stayed but on one occasion reverted and i'm not sure what was different to cause this. 
However one of the legion/linux forums has suggested changing /sys/module/snd_hda_intel/parameters/power_save_controller to 'N' as well.

So the last couple of weeks I have a script that changes these values at boot and everything appears to be fine. From what I've been reading this effects several distros.

Thank you for your time and help.

Comment 6 Brynn Dunlop 2024-07-20 12:45:00 UTC

And as soon as I've decided to send that last message it has reverted again. This is with power_save set as 0 and power_save_controller set to N
It is still much much better than it was

Comment 7 Takashi Iwai 2024-07-21 08:44:34 UTC

The problem is that there are other services that tune power_save option dynamically, hence the value you wrote can be overridden at any time later.

Could you check the value in /sys/modules/snd_hda_intel/parameters/power_save and whether it's still 0 or not if the problem appears?  If it's non-zero, then it's likely the service changing power_save parameter triggered the problem again.  If it's kept 0 but the bug appears, it means that the original problem can be somewhere else.

Comment 8 Takashi Iwai 2024-07-21 08:50:28 UTC

I'm building a test kernel with the enhancement of pm_blacklist option for snd-hda-intel in OBS home:tiwai:bsc1226449 repo.
Once after the build finishes, it'll appear at
  http://download.opensuse.org/repositories/home:/tiwai:/bsc1226449/standard/

Please install the kernel from there later, and boot with snd_hda_intel.pm_blacklist=2 boot parameter.  This should keep the runtime PM disabled no matter which power_save option is set.