Bug 1584463 - After upgrade to kernel-4.17.0 rc6 (but still running FC27), I hear thumps in the audio
Summary: After upgrade to kernel-4.17.0 rc6 (but still running FC27), I hear thumps in...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-31 01:23 UTC by Corey Ashford
Modified: 2019-02-21 21:12 UTC (History)
21 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-21 21:12:42 UTC


Attachments (Terms of Use)
Output of alsa-info.sh (45.85 KB, text/plain)
2018-05-31 01:23 UTC, Corey Ashford
no flags Details

Description Corey Ashford 2018-05-31 01:23:01 UTC
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:

Comment 1 Corey Ashford 2018-05-31 18:39:22 UTC
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.

Comment 2 Hans de Goede 2018-06-04 14:39:02 UTC
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

Comment 3 Corey Ashford 2018-06-08 00:03:57 UTC
(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.

Comment 4 Hans de Goede 2018-06-08 07:52:54 UTC
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

Comment 5 Corey Ashford 2018-06-08 17:48:26 UTC
(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!

Comment 6 Jim Scarborough 2018-06-28 16:34:05 UTC
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.

Comment 7 Justin M. Forbes 2018-07-23 15:08:40 UTC
*********** 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.

Comment 8 Jim Scarborough 2018-07-27 21:00:54 UTC
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).

Comment 9 Benjamin Berg 2018-09-17 09:48:17 UTC
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.

Comment 10 Corey Ashford 2018-09-17 17:17:00 UTC
(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.

Comment 11 Corey Ashford 2018-09-17 17:35:11 UTC
(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.

Comment 12 Benjamin Berg 2018-09-17 18:40:01 UTC
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).

Comment 13 Corey Ashford 2018-09-17 20:29:59 UTC
% 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

Comment 14 Hans de Goede 2018-09-17 20:37:19 UTC
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.

Comment 15 Corey Ashford 2018-09-17 20:39:12 UTC
(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!

Comment 16 Justin M. Forbes 2019-01-29 16:27:02 UTC
*********** 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.

Comment 17 Justin M. Forbes 2019-02-21 21:12:42 UTC
*********** 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.


Note You need to log in before you can comment on or make changes to this bug.