Created attachment 1446027 [details] Output of alsa-info.sh Description of problem: Because I have been having boot problems with my Lenovo P50, when the laptop is docked and has external monitors attached, I upgraded my Fedora 27 release to a Fedora-built 4.17.0-rc6 kernel. This new kernel doens't have the problem with monitors when docked, but now the sound system creates a "thump" sound when starting to play a sound, and then a smaller thump sound about 5 seconds after the sound stops playing. In https://bugzilla.redhat.com/show_bug.cgi?id=1573080#c18 Jeremy Cline mentioned this is probably a power management issue, and asked that I attached the output of alsa-info.sh Version-Release number of selected component (if applicable): kernel-4.17.0-0.rc6.git0.1.fc29.x86_64 How reproducible: Every time a sound is played Steps to Reproduce: 1. Play any sound 2. Hear the thump when it starts 3. Hear the thump a few seconds after it stops. Actual results: thump Expected results: no thump Additional info:
An important detail to add: I'm hearing the thump in a pair of headphones I have plugged into the headphone jack of the laptop, which I believe is this device: 0 [PCH ]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xb4740000 irq 132 I'm not using USB to C-media device, nor the HDMI-based audio. If I have an audio source playing continuously (I happen to like https://rain.today ) there are no thumps. This all seems to suggest the power-control hypothesis is right.
Hi Corey, F28+ kernel builds have audio-power management enabled, have you tried passing "snd_hda_intel.power_save=0" on the kernel command line as Jeremy suggested? Regards, Hans
(In reply to Hans de Goede from comment #2) > Hi Corey, > > F28+ kernel builds have audio-power management enabled, have you tried > passing "snd_hda_intel.power_save=0" on the kernel command line as Jeremy > suggested? > > Regards, > > Hans Sorry for the delay. I just now tried it, and yes that does in fact stop the thumping. I think I will leave the power_save turned off, since when the sound first comes on, not only do I hear a thump, the sound level "ramps up", so that the first sounds out of the speaker are at a lower volume and doesn't sound particularly good. If there's no way around that behavior, I'd suggest changing the power down timeout to something much longer, like five minutes instead of about nine seconds as it is now. I'd be kind of surprised if the amplifier draws that much current while it's idle, anyway.
Hi, We have a P50 in the Munich office and Benjamin (a colleague of mine) is looking into a proper fix for this. In the mean time using "snd_hda_intel.power_save=0" is a good workaround. As for the amount of power used you will be surprised, enabling power-saving for the HDA codec saves about 0.4W of idle power consumption. Which is significant even on the P50, but esp. on more light weight machines. My 12" 1kg Apollo Lake based travel laptop uses about 3-4W when idle (with the LCD panel on), so 0.4W is a huge extra current draw there. Regards, Hans
(In reply to Hans de Goede from comment #4) ... > As for the amount of power used you will be surprised, enabling power-saving > for the HDA codec saves about 0.4W of idle power consumption. Which is > significant even on the P50, but esp. on more light weight machines. My 12" > 1kg Apollo Lake based travel laptop uses about 3-4W when idle (with the LCD > panel on), so 0.4W is a huge extra current draw there. Good to know, thanks. My first thought was "disable it while it's charging", but that would decrease the rate at which the batteries are recharging (if only slightly), and is a waste of energy anyway. I'd be interested to know what the proper fix ends up being. Thanks again!
Doubtful there is an energy-efficient software solution, but I've noticed a hum 3700 Hz, 0.5% volume (http://www.szynalski.com/tone-generator/#3700,saw,v0.005) on the P50 when the audio is (apparently) turned off. I wish it were grounded when the amp is off.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.17.7-200.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
I changed my kernel command to include "snd_hda_intel.power_save=0" as suggested here to prevent audio power-save because the hum was driving me nuts. As an added bonus, I notice the system freezes much less often with that changes - down from about 2 boots a day (usually because of seized display) to about one every other day (mostly because of blank display).
Note that this issue should be solved upstream with commit d5a6cabf02210b896a60eee7c04c670ee9ba6dca ("ALSA: hda/realtek - Fix pop noise on Lenovo P50 & co") in kernel 4.18-rc3.
(In reply to Benjamin Berg from comment #9) > Note that this issue should be solved upstream with commit > d5a6cabf02210b896a60eee7c04c670ee9ba6dca ("ALSA: hda/realtek - Fix pop noise > on Lenovo P50 & co") in kernel 4.18-rc3. % git describe --contains d5a6cabf02210b896a60eee7c04c670ee9ba6dca v4.18-rc3~25^2~13 Since Fedora 27 is still taking the latest kernels, I will dnf update to 4.18.7 and see how it goes.
(In reply to Corey Ashford from comment #10) > (In reply to Benjamin Berg from comment #9) > > Note that this issue should be solved upstream with commit > > d5a6cabf02210b896a60eee7c04c670ee9ba6dca ("ALSA: hda/realtek - Fix pop noise > > on Lenovo P50 & co") in kernel 4.18-rc3. > > % git describe --contains d5a6cabf02210b896a60eee7c04c670ee9ba6dca > v4.18-rc3~25^2~13 > > Since Fedora 27 is still taking the latest kernels, I will dnf update to > 4.18.7 and see how it goes. Seems to work almost too well! How do I confirm that the audio system actually powered down? I hear no click at all.
There are different ways. Autosuspend happens after 5 seconds. So if you trigger a sound effect after that time, you may actually notice that the start of it is muted. powertop will tell you whether the codec is suspended or not. Other than that, I believe you can check /sys/class/sound/hw*/power/runtime_status (not sure which one exactly, and on my machine it seems like the codec is not suspended at least currently).
% uname -a Linux cjashfor-P50 4.18.7-100.fc27.x86_64 #1 SMP Thu Sep 13 18:41:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux From powertop: 100.0% Audio codec hwC0D0: Realtek (pulseaudio ) 100.0% PCI Device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller This is after having no sound playing for about one minute. So I'm guessing something has gone wrong with the auto-poweroff. I just checked my kernel command line, and I didn't disable power_save: % cat /proc/cmdline BOOT_IMAGE=//vmlinuz-4.18.7-100.fc27.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.luks.uuid=luks-985c9d8d-f922-4dc1-aa6b-15aa73337256 rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8 % cat /sys/class/sound/hw*/power/runtime_status unsupported unsupported % cat /sys/class/sound/*/power/runtime_status unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported unsupported
auto power-off is only enabled in F28 and later, you likely got it with 4.17-rc5 because that was build for F28 or rawhide. If you install the F28 version off the kernel from koji you should get power-management for the audio-codec.
(In reply to Hans de Goede from comment #14) > auto power-off is only enabled in F28 and later, you likely got it with > 4.17-rc5 because that was build for F28 or rawhide. > > If you install the F28 version off the kernel from koji you should get > power-management for the audio-codec. Ah, ok. Gotcha. I will probably update to F28 soon anyway, so I will just wait till then. Thanks!
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 28 kernel bugs. Fedora 28 has now been rebased to 4.20.5-100.fc28. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 29, and are still experiencing this issue, please change the version to Fedora 29. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.