Bug 218609
Summary: | snd-hda-intel sofhdadsp inaccurate speaker sound missing 0.8sec WAKEUP TIME FROM POWERSAVE STATE on Tiger Lake notebook MSI GP76 11UG 11800h | ||
---|---|---|---|
Product: | Drivers | Reporter: | FRANK S (f2g3t7) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | RESOLVED DUPLICATE | ||
Severity: | high | ||
Priority: | P3 | ||
Hardware: | Intel | ||
OS: | Linux | ||
See Also: | https://bugzilla.kernel.org/show_bug.cgi?id=11839 | ||
Kernel Version: | 6.8.1 upstream | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
lspci > lspci.txt
Screenshot of Manajaros installed ALSA/sound related packages short video of system settings audio test output of alsa-info.sh sudo dmesg > dmesg.txt oem28.inf file from w10 driver oem29.inf file from w10 driver oem30.inf file from w10 driver record of the audio test with and without background audio workaround |
Description
FRANK S
2024-03-17 06:11:31 UTC
Thank you for looking into this. Created attachment 306001 [details]
lspci > lspci.txt
Created attachment 306006 [details]
Screenshot of Manajaros installed ALSA/sound related packages
Created attachment 306023 [details]
short video of system settings audio test
Created attachment 306031 [details]
output of alsa-info.sh
output of alsa-info.sh
Created attachment 306037 [details]
sudo dmesg > dmesg.txt
sudo dmesg > dmesg.txt
Created attachment 306046 [details]
oem28.inf file from w10 driver
Created attachment 306047 [details]
oem29.inf file from w10 driver
oem29.inf file from w10 driver
Created attachment 306048 [details]
oem30.inf file from w10 driver
oem30.inf file from w10 driver
KDE System Settings Audio Test doesn't work correctly. ALSA Sound tests also produce same kind of flaw. incomplete played sound fragments. Some Videos on youtube also show the flaw, audio streams with interruptions. On the other hand not all media playback is affected of it. I tried position_fix 1,2 and 5 not effective. As I see that too many Bugs get opened in much worse state of audio problems, I consider my case not worth mentioning. so I'll close it. I reopen this report, because I seem to have understood what might be going on: The sound takes approximately 0.8 seconds to wake up from a power save state. This can be prevented by keeping audio busy playing some long sound piece "in the background". Please take a look at report 11839. It describes what I do see now - 16 years later. 11839 has been closed a unreproducible after hanging some years. I tried the following to solve the problem myself: 1. options snd_hda_intel power_save=0 or 1000 >reboot,visible in /sys/module/snd_hda_intel/parameters, but no effect 2. options snd_hda_intel power_save_controller=N >reboot, visible in /sys/module/snd_hda_intel/parameters, but no effect I raised the importance to high to get some attention. If you could give me a hint what I'm doing wrong ? how can a power management blacklist entry for gp76's ALC298 on snd-hda-intel be made ? how can power save state be prevented ? OK, I've set power_save=0 and power_save_controller=0 in intel_hda.c and built the kernel. restarting the system I verified the settings again in sys/module and they were correctly set. But the problem wasn"t solved that way. My amateur conclusion is, the ALC298 and sofhdadsp have their own power management settings somewhere. I don"t know. what I'll do now is record the audio situation with my mobile and without the workaround of playing a continuous wav stream an how it changes the ability of the system to do the audio test front left/right. More I can't do now. I hope ALSA developer team will come up with a solution/hints. Created attachment 306053 [details]
record of the audio test with and without background audio workaround
record of the audio test with and without background audio workaround
the workaround also corrects the problem with longer youtube videos. These videos are not only affected the first 0.8 seconds. The ALC298 or whatever component starts sleeping evr and ever again during the minutes long videos. Butit would be nice if we had a solution for the phenomenon... *** This bug has been marked as a duplicate of bug 218709 *** |