Created attachment 1366788 [details]
Recorded click with my phone

I recorded the clicks with my phone.

I hear this too. I think this is kernel issue.

Kernel 4.13.16-302.fc27.x86_64 works for me

kernel-4.14.3-300.fc27.x86_64 clicking noise
kernel-4.14.5-300.fc27.x86_64 clicking noise

00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)
        Subsystem: Gigabyte Technology Co., Ltd Device a002
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

Can you pass snd_hda_intel.power_save=0 on the kernel command line and see if that resolves your issue?

Thanks

Yes, that seems to resolve this for me.

Hi,

(In reply to Riku Seppala from comment #4)
> Yes, that seems to resolve this for me.

Ok, thank you for testing. I need to discuss with the upstream alsa developers how to best handle this (without disabling audio codec power saving for everyone.

I'll get back to you when I've some more info.

Regards,

Hans

Oh, there is one thing which you can test right away:

Change "snd_hda_intel.power_save=0" to "snd_hda_intel.power_save=5", the number is the number of seconds before the audio turns off when the last app stops playing. The actual time between stopping the last app playing and the click from the codec going into power-saving may be different because pulseaudio is also in the loop. Anyways the idea is to make the delay long enough to do the following:

1) Start playing audio
2) Open pavucontrol ("sudo dnf install pavucontrol" if necessary)
3) go to the "Output Devices" tab in pavucontrol
4) Stop playing audio
5) Before the click-noise, go back to pavucontrol and mute the playback device you are using (click the green checkmark icon)
6) Wait for the timeout (+ some extra) do you still hear a click ?

I hope that this will cure the click, at which point we need to teach the kernel to auto-mute before entering power-saving.

I did some testing and I don't know if this helps at all. Also my hearing may not be very good but here goes: First, I only hear the click when I start playing audio. Not when I stop it, no matter how long I wait. But I do hear it when I reboot/shutdown. It also clicks during boot when KDE is loading. This is with kernel-4.14.3-300

With kernel 4.13.16-302 (the one that works) I do hear click early on the boot, with 4.14.3-300 click comes later during boot.

So it never was perfect but one click sound during boot I can live it.

Thank you for testing, what if you mute the output in pavucontrol, then start playing music, then unmute, do you still get the click before the music starts then ?

No. But I'm not 100% sure. I noticed when I start playing and it clicks and then stop and immediately start playing again, there is no click. I did try waiting awhile before trying that.

And btw, I hear click when starting pavucontrol. :) but that might some because of this?
$ pavucontrol 

(process:2095): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.

(In reply to Riku Seppala from comment #9)
> No.

No, as in "No I do not hear a click if I start playing music with the volume muted and then unmute", correct?

> And btw, I hear click when starting pavucontrol. :) but that might some
> because of this?
> $ pavucontrol 
> 
> (process:2095): Gtk-WARNING **: Locale not supported by C library.
>         Using the fallback 'C' locale.

No, that just means that starting pavucontrol causes the codec to wakeup, so that might be a better test, mute the volume, then wait long enough for power-saving to kick in, then start pavucontrol.

Thank you for all your input, your testing is very useful.

(In reply to Hans de Goede from comment #10)
> (In reply to Riku Seppala from comment #9)
> > No.
> 
> No, as in "No I do not hear a click if I start playing music with the volume
> muted and then unmute", correct?

Correct.

> No, that just means that starting pavucontrol causes the codec to wakeup, so
> that might be a better test, mute the volume, then wait long enough for
> power-saving to kick in, then start pavucontrol.
> 
> Thank you for all your input, your testing is very useful.

Actually, I just tried that. I muted sound from bottom right corner "audio volume settings" and started pavucontrol, I hear click.

(In reply to Riku Seppala from comment #12)
> > No, that just means that starting pavucontrol causes the codec to wakeup, so
> > that might be a better test, mute the volume, then wait long enough for
> > power-saving to kick in, then start pavucontrol.
> > 
> > Thank you for all your input, your testing is very useful.
> 
> Actually, I just tried that. I muted sound from bottom right corner "audio
> volume settings" and started pavucontrol, I hear click.

That might not do the same thing as actually muting the output device in pavucontrol, can you try that please?

OK I did this:
1. muted from pavucontrol
2. closed pavucontrol
3. waited few minutes
4. start pavucontrol
5. I hear click

Was that what you meant?

Workaround is working with all of kernels, sound is clean:

# echo "options snd_hda_intel power_save=0" > /etc/modprobe.d/alsa-base.conf

(In reply to Riku Seppala from comment #14)
> OK I did this:
> 1. muted from pavucontrol
> 2. closed pavucontrol
> 3. waited few minutes
> 4. start pavucontrol
> 5. I hear click
> 
> Was that what you meant?

Assuming you muted using the green checkbox on the "Output Devices" tab, then yes that is what I meant, thanks.

Riku, David,

Can you both let me know the brand and model of the hardware (motherboard if not a laptop) you are using?

I believe I need to find some way to reproduce this myself so that I can hopefully find a fix while keeping the HDA codec power-saving active, as that is important for laptops.

Regards,

Hans

(In reply to Hans de Goede from comment #17)
> Can you both let me know the brand and model of the hardware (motherboard if
> not a laptop) you are using?

I’m neither Riku nor David, but the bug occurs here on my desktop with a ASRock B85M-ITX motherboard.

(In reply to Hans de Goede from comment #16)
> (In reply to Riku Seppala from comment #14)
> > OK I did this:
> > 1. muted from pavucontrol
> > 2. closed pavucontrol
> > 3. waited few minutes
> > 4. start pavucontrol
> > 5. I hear click
> > 
> > Was that what you meant?
> 
> Assuming you muted using the green checkbox on the "Output Devices" tab,
> then yes that is what I meant, thanks.

I muted using the speaker icon with x, that says "Mute audio" when I hover mouse over it. There is button with green on but it says "Set as fallback" and I dont see it does anything?

My motherboard is Gigabyte P55A-UD3

kernel-4.14.6-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-129969aa8a

kernel-4.14.6-300.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-129969aa8a

kernel-4.14.6-200.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ba6b6e71f7

Answer for question at https://bodhi.fedoraproject.org/updates/kernel-4.14.4-200.fc26#comment-708994
pactl list

<cut>
Sink #0
	State: SUSPENDED
	Name: alsa_output.pci-0000_00_1b.0.analog-surround-51
	Description: Internes Audio Analog Surround 5.1
	Driver: module-alsa-card.c
	Sample Specification: s16le 6ch 48000Hz
	Channel Map: front-left,front-right,rear-left,rear-right,front-center,lfe
	Owner Module: 7
	Mute: no
	Volume: front-left: 51659 /  79% / -6.20 dB,   front-right: 43801 /  67% / -10.50 dB,   rear-left: 43466 /  66% / -10.70 dB,   rear-right: 49145 /  75% / -7.50 dB,   front-center: 43801 /  67% / -10.50 dB,   lfe: 0 /   0% / -inf dB
	        balance -0.02
	Base Volume: 65536 / 100% / 0.00 dB
	Monitor Source: alsa_output.pci-0000_00_1b.0.analog-surround-51.monitor
	Latency: 0 usec, configured 0 usec
	Flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY 
	Properties:
		alsa.resolution_bits = "16"
		device.api = "alsa"
		device.class = "sound"
		alsa.class = "generic"
		alsa.subclass = "generic-mix"
		alsa.name = "AD1989B Analog"
		alsa.id = "AD1989B Analog"
		alsa.subdevice = "0"
		alsa.subdevice_name = "subdevice #0"
		alsa.device = "0"
		alsa.card = "0"
		alsa.card_name = "HDA Intel"
		alsa.long_card_name = "HDA Intel at 0xfcff8000 irq 27"
		alsa.driver_name = "snd_hda_intel"
		device.bus_path = "pci-0000:00:1b.0"
		sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
		device.bus = "pci"
		device.vendor.id = "8086"
		device.vendor.name = "Intel Corporation"
		device.product.id = "3a3e"
		device.product.name = "82801JI (ICH10 Family) HD Audio Controller (P5Q Deluxe Motherboard)"
		device.form_factor = "internal"
		device.string = "surround51:0"
		device.buffering.buffer_size = "1058400"
		device.buffering.fragment_size = "529200"
		device.access_mode = "mmap+timer"
		device.profile.name = "analog-surround-51"
		device.profile.description = "Analog Surround 5.1"
		device.description = "Internes Audio Analog Surround 5.1"
		alsa.mixer_name = "Analog Devices AD1989B"
		alsa.components = "HDA:11d4989b,10438311,00100300"
		module-udev-detect.discovered = "1"
		device.icon_name = "audio-card-pci"
	Ports:
		analog-output-lineout: Line-Ausgang (priority: 9900, available)
	Active Port: analog-output-lineout
	Formats:
		pcm
<cut>

My board is a asus P5Q_Deluxe (not very new :-)) and i use a 5.1 loudspeaker system from logitec.

Well it's normal that i hear a noise in my speakers if i start the system from grub2 until kernel finishing sound setup.
But with 'power-saving active' the noise come back with further booting and in X session.
It's the same noise if you unplug a electric guitar from an amplifier if you forgot to power off the amplifier first.
In other words a noise because of a missing input source.
It looks like power saving simply disable the sound device which will always cause an problem like this if the sound system isn't power off too.
Anyway, i am happy to do more testing.

kernel-4.14.6-200.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-ba6b6e71f7

kernel-4.14.6-300.fc27.x86_64 fixed it for me

Dell Latitude E5530

How can one see what the actual code change was? I don't see a link here.

(In reply to Aleksandar Kostadinov from comment #27)
> How can one see what the actual code change was? I don't see a link here.

There has been no code change, we've changed the snd_hda_intel.power_save option default value back to 0, disabling codec power-management, at least for Fedora 27. I'm looking into a better fix for this for Fedora 28.

kernel-4.14.6-300.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

kernel-4.14.6-200.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Hi All,

So this bug has been closed because this is fixed by disabling the codec autosuspend for F26 and F27. But for F28 we are going to turn this on by default as it results in a significant power-saving.

The plan is to use a blacklist for devices on which this causes issues and I need your help to populate this blacklist, getting your device on this list know means that things will just work when you upgrade to F28 later.

First of all to test this I need you to (temporarily) switch to running a Fedora 28 kernel, download these 2 files:

https://kojipkgs.fedoraproject.org//packages/kernel/4.15.0/1.fc28/x86_64/kernel-core-4.15.0-1.fc28.x86_64.rpm
https://kojipkgs.fedoraproject.org//packages/kernel/4.15.0/1.fc28/x86_64/kernel-modules-4.15.0-1.fc28.x86_64.rpm

(from: https://koji.fedoraproject.org/koji/buildinfo?buildID=1021748)

And then run:

sudo rpm -ivh kernel-core-4.15.0-1.fc28.x86_64.rpm kernel-modules-4.15.0-1.fc28.x86_64.rpm

And reboot into the new kernel.

cat /sys/module/snd_hda_intel/parameters/power_save

Should now output 1 and this should give you the sound problems this bug was originally about again. If not do "uname -r" to make sure you are running the 4.15.0-1.fc28.x86_64 kernel and if you are, you got lucky and the bug got fixed in the latest kernel :)

So assuming you can now reproduce the problem, it is time to create a blacklist entry:

1) Download: https://fedorapeople.org/~jwrdegoede/90-hda-powersave.rules
and copy it to /etc/udev/rules.d

2) Download: https://fedorapeople.org/~jwrdegoede/90-snd_hda_intel.hwdb
and copy it to /etc/udev/hwdb.d

3) Edit /etc/udev/hwdb.d/90-snd_hda_intel.hwdb and add an entry for your device there, lets take a look at the example entry:

# Match string formats:
# snd_hda_intel:<pci-subsys-vendor-id>:<pci-subsys-device-id>:dmi:<dmi string>

snd_hda_intel:0x1849:0x5892:dmi:*rvnASRock:rnB150MPro4S/D3:*
 SND_HDA_INTEL_POWERSAVE=0

There are 3 device specific parts you need to fill in, lets star with the pci-subsys-vendor-id and pci-subsys-device-id. Run:

lspci | grep "HD Audio"

This outputs e.g.:
00:1f.3 Audio device: Intel Corporation Sunrise Point-H HD Audio (rev 31)

Now get detailed info on that device:

[hans@shalem ~]$ lspci -v -n -s 00:1f.3
00:1f.3 0403: 8086:a170 (rev 31)
        Subsystem: 1849:5892
        ...

And after the Subsystem: are the values you are looking for.

The last device specific bit you need is the dmi modalias for your system:

cat /sys/class/dmi/id/modalias

On my example system this gives:

dmi:bvnAmericanMegatrendsInc.:bvrP7.00:bd12/06/2016:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnB150MPro4S/D3:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:

Notice that I've shortened this to: 

dmi:*rvnASRock:rnB150MPro4S/D3:*

Replacing uninteresting bits with a simple "*" as well as replacing the bios-data (bd) and bios-version (bvr) fields as those may vary depending on the installed BIOS version and we want to match all versions.

Add a new entry for your device using the info from above.

4) To use this new info run:
sudo systemd-hwdb update
sudo udevadm trigger

5) Verify that power_save now is 0:
cat /sys/module/snd_hda_intel/parameters/power_save

6) Reboot, check that power_save is set to 0 again and that the sound problems are gone.


As mentioned in the 90-snd_hda_intel.hwdb file I've to insist on people filing a bug for this at https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers using component "Sound(ALSA)" and then add a link to the filed bug report as a comment to the hwdb entry you've added for this.

Once you've a working hwdb entry with a comment to a bugzilla.kernel.org bug for this, please attach your modified 90-snd_hda_intel.hwdb here. Once I've gathered a few entries I will submit these files for upstream systemd inclusion.

Thanks & Regards,

Hans

Not sure if a blacklist will fix my problem , mentioned here https://bugzilla.redhat.com/show_bug.cgi?id=1525104#c23

I see that with a new motherboard too.
If the onboard card will be suspend than i hear a ugly noise in my sound system, which isn't powered off.

Well it is a nice idea to suspend notebooks which are normal not used for a soundsystem.
But for a normal PR or HPC with a fixed soundsystem you will always run in this problem.
Any way, i know how to fix it for myself.

(In reply to Wolfgang Ulbrich from comment #32)
> Not sure if a blacklist will fix my problem , mentioned here
> https://bugzilla.redhat.com/show_bug.cgi?id=1525104#c23
> 
> I see that with a new motherboard too.
> If the onboard card will be suspend than i hear a ugly noise in my sound
> system, which isn't powered off.

I don't see this as any different as the laptop problem, the hda codec drivers should make sure to put the codec in a state where it e.g. connects the line out signals to ground, rather then leave them floating.

Although it may be that your specific set of speakers is more sensitive to floating signals then others.

A quick update on this, I submitted a pull-req to systemd (udev) upstream to add the rules and hwdb files and they had some rightful worries about this approach, see: https://github.com/systemd/systemd/pull/8128

So now the plan is changed to deal with this inside the kernel instead, using pci subsys vendor- and device-id matching. This will also allow the quirk to disable-power-saving to be removed in sync with any kernel fixes which make it no longer necessary.

So instead of testing the udev and hwdb files I mentioned earlier, if you are impacted by this, please run: "lspci -v -nn" and attach the output here. Please also add a comment which vendor and model device you are seeing problems on and what the problems are.

Created attachment 1393169 [details]
output of lspci for ASRock MB

Created attachment 1394128 [details]
lspci-asus-prime-x370-pro

Thank you for the info, I'm working on getting a blacklist for this upstream, ideally the upstream kernel ALSA maintainers would like to actually fix the problem, rather then disable power-saving. In order to debug this further they need alsa-info.sh output, can you please run:

alsa-info.sh --no-upload

And attach the generated file here?

Created attachment 1399349 [details]
alsa-info asus prime x370-Pro

I've prepared a scratch kernel-build (note still building atm) with the discussed power-saving blacklist here:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25234129

Here are instructions for how to download and test a kernel from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

After booting into the new kernel, do:
dmesg | grep "is on the power_save blacklist"

This should return a line with the PCI subsys ids of your HDA card, also:
"cat /sys/module/snd_hda_intel/parameters/power_save" should return "0" and last but not least, your sound should work without any issues of course.

Forget about that test-kernel please, it is no good. I will prepare a new one.

A fixed test-build is now building here, please test once it is done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25235331

I rebuild the kernel for f28.
It seems to be working, but one output is weird.

[root@mother rave]# dmesg | grep "is on the power_save blacklist"
[    6.666766] snd_hda_intel 0000:0c:00.3: device 1043:8733 is on the power_save blacklist, forcing power_save to 0
[root@mother rave]# cat /sys/module/snd_hda_intel/parameters/power_save
-1

(In reply to Wolfgang Ulbrich from comment #42)
> I rebuild the kernel for f28.
> It seems to be working, but one output is weird.
> 
> [root@mother rave]# dmesg | grep "is on the power_save blacklist"
> [    6.666766] snd_hda_intel 0000:0c:00.3: device 1043:8733 is on the
> power_save blacklist, forcing power_save to 0
> [root@mother rave]# cat /sys/module/snd_hda_intel/parameters/power_save
> -1

Thank you, the -1 is normal, my bad. -1 means not set, which will make it use the builtin default of "1" + the blacklist.

Created attachment 1429694 [details]
alsa-info.sh for Acer Aspire 5930G

I have the same problem. Disabling power saving helps.
Here is my lspci -v -nn

00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio Controller [8086:293e] (rev 03)
        Subsystem: Acer Incorporated [ALI] Device [1025:013f]
        Flags: bus master, fast devsel, latency 0, IRQ 28
        Memory at f6500000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [130] Root Complex Link
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

Hi,

(In reply to NSLW from comment #44)
> Created attachment 1429694 [details]
> alsa-info.sh for Acer Aspire 5930G
> 
> I have the same problem. Disabling power saving helps.
> Here is my lspci -v -nn
> 
> 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio
> Controller [8086:293e] (rev 03)
>         Subsystem: Acer Incorporated [ALI] Device [1025:013f]
>         Flags: bus master, fast devsel, latency 0, IRQ 28
>         Memory at f6500000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
>         Capabilities: [100] Virtual Channel
>         Capabilities: [130] Root Complex Link
>         Kernel driver in use: snd_hda_intel
>         Kernel modules: snd_hda_intel

Thank you, I'm currently on vacation. I will prepare a test-kernel with a patch adding a quirk for your hardware next week.

Regards,

Hans

Hi Hans,

here's my /etc/udev/hwdb.d/91-snd_hda_intel-local.hwdb for Intel NUC5i7RYB:

#########################################
# Intel
#########################################

# NUC5i7RYB
# https://bugzilla.kernel.org/show_bug.cgi?id=199607
snd_hda_intel:0x8086:0x2057:dmi:*rvnIntelCorporation:rnNUC5i7RYB:*
 SND_HDA_INTEL_POWERSAVE=0

NSLW, Viktor,

Thanks for the info. I've just started a scratch-build of the F28 kernel with patches added adding quirks for your device. Never mind the rhbz1572975 in the kernel-version this test build also contains patches adding quirks for your 2 devices (Acer Aspire 5930G, NUC5i7RYB).

With this build the audio problems should be gone without needing a kernel cmdline argument. The test-kernel is currently building here (this takes a couple of hours): https://koji.fedoraproject.org/koji/taskinfo?taskID=26837978

Here are instructions for installing and testing a test-kernel from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

Please let me know if this fixes things, then I can submit the patch adding the quirk to the official Linux kernel.

Thanks & Regards,

Hans

NSLW, Viktor,

The test kernel is done building now, if you can find some time to test it soon(ish) that would be great.

Regards,

Hans

lspci -v -nn -s 00:1b.0
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05)
        Subsystem: Gigabyte Technology Co., Ltd Device [1458:a002]
        Flags: bus master, fast devsel, latency 0, IRQ 39
        Memory at fbff8000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Capabilities: [100] Virtual Channel
        Capabilities: [130] Root Complex Link
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

(In reply to Riku Seppala from comment #49)
> lspci -v -nn -s 00:1b.0
> 00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset
> High Definition Audio [8086:3b56] (rev 05)
>         Subsystem: Gigabyte Technology Co., Ltd Device [1458:a002]
>         Flags: bus master, fast devsel, latency 0, IRQ 39
>         Memory at fbff8000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
>         Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
>         Capabilities: [100] Virtual Channel
>         Capabilities: [130] Root Complex Link
>         Kernel driver in use: snd_hda_intel
>         Kernel modules: snd_hda_intel

Thanks, I will write a patch adding a quirk for your machine when I find some time for this. Can you please also run alsa-info.sh and attach the file it generates here?

Created attachment 1434390 [details]
alsa info

I'm getting issues with pops when playback starts. Continuous playback (eg. music) is fine. It's just things like notification sounds when no other sound is playing.

Passing "snd_hda_intel.power_save=0" as a kernel parameter fixes the issue.

Running Fedora 28, all updates. Motherboard is a Gigabyte GA-Z87X-UD3H, which uses a Realtek ALC898 codec.

Created attachment 1435032 [details]
lspci -v -nn -s 00:1b.0 for Gigabyte GA-Z87X-UD3H

Created attachment 1435033 [details]
alsa-info.sh --no-upload for Gigabyte GA-Z87X-UD3H

I lied, motherboard is a Gigabyte Z87-D3HP with a Realtek ALC892 codec. The above attachments still apply.

Created attachment 1435114 [details]
lspci -v -nn -s 00:1b.0 for Asrock H81M-HDS

I see similar noise with an Asrock H81M-HDS board with a Realtek ALC662 codec. Again, continuous playback is fine, sudden noises in isolation cause pops.

Passing "snd_hda_intel.power_save=0" as a kernel parameter fixes the issue.

Fedora 28, fully updated.

Created attachment 1435115 [details]
alsa-info.sh --no-upload for Asrock H81M-HDS

(In reply to NSLW from comment #44)
> Created attachment 1429694 [details]
> alsa-info.sh for Acer Aspire 5930G
> 
> I have the same problem. Disabling power saving helps.

In general, power_save=0 is the last resort, so let's try to add blacklisting once after all other workarounds fail.

As the most commonly seen workaround, turn off "Loopback Mixing" in the mixer setup.  This helps in a lot of cases:
  % amixer -c0 set "Loopback Mixing" Disabled

Sometimes the analog codec is on the secondary controller (e.g. on Haswell or Broadwell).  In that case, pass -c1 instead.

In this case (in comment 44), though, it's already off, judging from alsa-info.sh output.  Another possible workaround for ALC882 is to use another shutup function, e.g. the patch below.  Unfortunately, this can't be changed on the fly, so you'd need to rebuild the kernel.

Last but not least, for Aspire 5930G, you may try to apply the fixup for Aspire 8930G.  For that, pass
  model=acer-aspire-8930g
option to snd-hda-intel module.  This may make some features broken, but it's only for checking the pop noise.

Created attachment 1435762 [details]
Test patch to change ALC882 codec shutup callback

NSLW,

I've started a test kernel-build with the patch from Takashi, please test this on your Acer Aspire 5930G and please also try the other suggestions from Takashi, ideally we can fix this without needing to disable powersaving. That will give you aprox. an extra half hour of battery life (on an idle machine).

The kernel is building here now, this should be finished in a couple of hours:
https://koji.fedoraproject.org/koji/taskinfo?taskID=27143141

See here for generic instructions for testing a kernel directly from koji:
https://fedorapeople.org/~jwrdegoede/kernel-test-instructions.txt

And please let us know the results of running this kernel (without the power_save=0 option) as well as the other suggestions from Takashi.

Regards,

Hans

Riku, Brandon,

I've send patches upstream to add your: Gigabyte P55A-UD3, Gigabyte Z87-D3HP and Asrock H81M-HDS boards to the snd_hda_intel.power_save blacklist.

Takashi may have some other solutions for you to try before we go with the blacklist.

Regards,

Hans

Hello,

I suspect I am having the same issue with power saving, as I am experiencing a loud "thunk" followed by static and hissing on my Dell E7450. I've tried disabling power saving by placing the following in /etc/modprobe.d/sound.conf:

options snd-hda-intel power_save=0

as well as:

options snd-hda-intel power_save=0

but the issue persists.

# cat /sys/module/snd_hda_intel/parameters/power_save
0


I am attaching the output of "alsa-info.sh --no-upload" as well as the output of lspci -v -nn.



Thanks.

Fully updated Fedora 28 x64
Dell Lattitude E7450

Created attachment 1440639 [details]
alsa-info from Dell E7450

Created attachment 1440640 [details]
Dell 7450 lspci -v -n Output

(In reply to Jason Scalia from comment #63)
> Hello,
> 
> I suspect I am having the same issue with power saving, as I am experiencing
> a loud "thunk" followed by static and hissing on my Dell E7450. I've tried
> disabling power saving by placing the following in
> /etc/modprobe.d/sound.conf:
> 
> options snd-hda-intel power_save=0
> 
> as well as:
> 
> options snd-hda-intel power_save=0
> 
> but the issue persists.
> 
> # cat /sys/module/snd_hda_intel/parameters/power_save
> 0
> 
> 
> I am attaching the output of "alsa-info.sh --no-upload" as well as the
> output of lspci -v -nn.
> 
> 
> 
> Thanks.
> 
> Fully updated Fedora 28 x64
> Dell Lattitude E7450

Correction:

That should have been:

> options snd-hda-intel power_save=0

and

options snd_hda_intel power_save=0 power_save_controller=N

(In reply to Jason Scalia from comment #63)
> 
> # cat /sys/module/snd_hda_intel/parameters/power_save
> 0

If you still have these issues even with this setting then you have a different problem, it is probably best to directly file a bug upstream for this:

https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers

And then select component Sound(ALSA)

Thank you, opened up https://bugzilla.kernel.org/show_bug.cgi?id=199815

Hans,

I tried your kernel build, the bug is still there, see alsa log with your kernel:
https://paste.gnome.org/pxjdow2o7

original kernel
https://paste.gnome.org/p4whkj24b

My Intel NUC NUC7i3BNB Realtek ALC283 card has static noise that goes away when I disable powersave.

Takashi Iwai,

please inform us if you have any other suggestion on how to fix the bug, thanks.

(In reply to mst from comment #69)
> I tried your kernel build, the bug is still there, see alsa log with your
> kernel:
> https://paste.gnome.org/pxjdow2o7
> 
> original kernel
> https://paste.gnome.org/p4whkj24b
> 
> My Intel NUC NUC7i3BNB Realtek ALC283 card has static noise that goes away
> when I disable powersave.

Assuming you mean the kernel build from comment 61, that was meant for NSLW's Acer Aspire 5930G which has an ALC882 codec, it is not surprising that that kernel does not help for your NUC. I've spend a patch upstream the blacklist the power-saving on your NUC and that has been expected, so that should show up in a Fedora kernel eventually. In the mean time you can keep using the module option to disable this.

Hans,

Well I was expecting to fix this bug in this thread. Now I see that the patch is only for ALC882, thanks. If you could patch the alc283 driver and generate a kernel I could test it as Takashi Iwai wrote
"In general, power_save=0 is the last resort, so let's try to add blacklisting once after all other workarounds fail."

Hans,

I'm sorry for the delay. I've just tested your kernel and can confirm that without additional configuration power_save is turned off:

$ cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-4.16.11-300.rhbz1520902.fc28.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8

$ cat /sys/module/snd_hda_intel/parameters/power_save
0

$ ls /etc/udev/hwdb.d | wc -l 
0


Thank you!

(In reply to Viktor Ashirov from comment #72)
> Hans,
> 
> I'm sorry for the delay. I've just tested your kernel and can confirm that
> without additional configuration power_save is turned off:
> 
> $ cat /proc/cmdline 
> BOOT_IMAGE=/vmlinuz-4.16.11-300.rhbz1520902.fc28.x86_64
> root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap
> rhgb quiet LANG=en_US.UTF-8

Ok, thank you for testing and also thank you for answering the info request on the kernel bugzilla about this. I've asked upstream to merge the patch adding the quirk for your NUC.

Takashi Iwai,
Do you know who can help debugging the intel hda ALC283 driver as I see the most popular thing to do now is blacklisting-disabling power save. Thanks.

There is no "ALC283 driver" problem.  It's a problem that is specific to each model, and this surfaced just because Fedora starting to set the default power_save to 1 recently (it's kernel config).

And, unfortunately, there is no silver bullet for this problem.  Each hardware implementation requires different workarounds.  Some works by replacing the pin shutup with EAPD shutup, some works with the loopback disablement, some works with extra COEF verbs, and some works with additional delays, etc, etc.
So, the only answer would be to try every possible quirk that would match with your own device.

Takashi Iwai,
Okay, so I am not a developer to write the code but I can test the workarounds on my system. Is there someone who can help me by writing the code?
My device info is in comment 69.

Upgraded to F28 today and the problem started occuring again on my ASRock B85M-ITX motherboard.

$ dmesg | grep "power_save"
[    5.465431] snd_hda_intel 0000:00:03.0: device 1849:0c0c is on the power_save blacklist, forcing power_save to 0

yet

$ cat /sys/module/snd_hda_intel/parameters/power_save
1

Created attachment 1449821 [details]
HP Omen 870 – 117 NS

Click happens to me with a desktop PC running Fedora 28, 4.16.13-300.fc28.x86_64.

Created attachment 1450242 [details]
Intel DQ35JO desktop motherboard  lspci output

Created attachment.  Same issue as others; clicking noise when starting videos and on other system events (Fedora 28).  Desktop motherboard: Intel DQ35JO (circa 2008).

Hi All,

Just a quick note that I'm seeing the various new "click noise" reports coming in, but ATM I don't have time to respond to them in detail. I hope to have some time for this again in about 2 weeks.

I the mean time adding "snd_hda_intel.power_save=0" to your kernel commandline can be used to work around this (the "fix" which I will do in 2 weeks most likely is to do this automatically for your board)

Regards,

Hans

(In reply to Alexandre Franke from comment #77)
> Upgraded to F28 today and the problem started occuring again on my ASRock
> B85M-ITX motherboard.
> 
> $ dmesg | grep "power_save"
> [    5.465431] snd_hda_intel 0000:00:03.0: device 1849:0c0c is on the
> power_save blacklist, forcing power_save to 0
> 
> yet
> 
> $ cat /sys/module/snd_hda_intel/parameters/power_save
> 1

I made a mistake, your boards has 2 HDA controllers and I added the subsystem device-id from the wrong one, so the kernel is now automatically disabling power-saving on your HDMI HDA instead of the one going to the analog jacks. I will fix this (and double check all other entries) when I've some time to work on this again. I the mean time adding "snd_hda_intel.power_save=0" to your kernel commandline can be used to work around this.

Hearing the clicking noise, even with the following work around:

[mskinner@beast ~]$ cat /sys/module/snd_hda_intel/parameters/power_save
0


My motherboard: 

Manufacturer: ASRock
Product Name: X399 Professional Gaming

Just started for me after updating to latest F.28 kernel:
4.17.6-200.fc28.x86_64

Created attachment 1469429 [details]
alsa-info.txt.asrock.x399-pro-gaming

Created attachment 1469435 [details]
lspci.asrock.x399-pro-gaming

For those who do not know, the right (workaround) command is:

$ sudo grubby --update-kernel=ALL --args='snd_hda_intel.power_save=0'

Created attachment 1471605 [details]
lspci output from Gigabyte H81M-DS2V system

Created attachment 1471606 [details]
alsa-info output for Gigabyte H81M-DS2V

Is this still the right way to report motherboards with this problem?

(In reply to marc skinner from comment #82)
> Hearing the clicking noise, even with the following work around:
> 
> [mskinner@beast ~]$ cat /sys/module/snd_hda_intel/parameters/power_save
> 0

In that case you are not impacted by this bug, but there is some other problem with the sound-driver for your machine.

Please file a bug here:

https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers

choose "Sound(ALSA)" as component and attach the file generated by alsa-info.sh to the bug.

(In reply to Jonathan Underwood from comment #88)
> Is this still the right way to report motherboards with this problem?

That depends on what the problem is you are seeing. The pci subsys-ids for your motherboard are already on the power_save blacklist. With a recent kernel, if you do:

dmesg | grep "power_save blacklist"

You should see a message like this:

"device 1458:a002 is on the power_save blacklist, forcing power_save to 0"

If you are still hearing audio clicks afer that you have a different problem, in that case please file a bug here:

https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers

choose "Sound(ALSA)" as component and attach the file generated by alsa-info.sh to the bug.

(In reply to Hans de Goede from comment #81)
> I made a mistake, your boards has 2 HDA controllers and I added the
> subsystem device-id from the wrong one, so the kernel is now automatically
> disabling power-saving on your HDMI HDA instead of the one going to the
> analog jacks. I will fix this (and double check all other entries) when I've
> some time to work on this again. I the mean time adding
> "snd_hda_intel.power_save=0" to your kernel commandline can be used to work
> around this.

Sorry for being slow with getting this fixed, I've just submitted a fix correcting the quirk upstream, this should eventually show up in the 4.17.x and 4.18.x stable releases.

(In reply to Hans de Goede from comment #91)
> Sorry for being slow with getting this fixed, I've just submitted a fix
> correcting the quirk upstream, this should eventually show up in the 4.17.x
> and 4.18.x stable releases.

Cheers!

Hi Hans,

Thanks for responding, and all the work you do on this. Comments below.

(In reply to Hans de Goede from comment #90)
> (In reply to Jonathan Underwood from comment #88)
> > Is this still the right way to report motherboards with this problem?
> 
> That depends on what the problem is you are seeing. The pci subsys-ids for
> your motherboard are already on the power_save blacklist. With a recent
> kernel, if you do:
> 
> dmesg | grep "power_save blacklist"
> 
> You should see a message like this:
> 
> "device 1458:a002 is on the power_save blacklist, forcing power_save to 0"
> 

I booted kernel 4.17.9-200.fc28.x86_64 and I don't see any such message in dmesg. Further, 

# cat /sys/module/snd_hda_intel/parameters/power_save
1

So, I don't believe the pci subsys-ids addition has worked as expected, unfortunately. Or perhaps the kernel isn't recent enough? (though it is the most recent F28 kernel). 

> If you are still hearing audio clicks afer that you have a different
> problem, in that case please file a bug here:
> 
> https://bugzilla.kernel.org/enter_bug.cgi?product=Drivers
> 
> choose "Sound(ALSA)" as component and attach the file generated by
> alsa-info.sh to the bug.

I have reported the bug here in any case: 

https://bugzilla.kernel.org/show_bug.cgi?id=200687

Hi,

(In reply to Jonathan Underwood from comment #93)
> Hi Hans,
> 
> Thanks for responding, and all the work you do on this. Comments below.
> 
> (In reply to Hans de Goede from comment #90)
> > (In reply to Jonathan Underwood from comment #88)
> > > Is this still the right way to report motherboards with this problem?
> > 
> > That depends on what the problem is you are seeing. The pci subsys-ids for
> > your motherboard are already on the power_save blacklist. With a recent
> > kernel, if you do:
> > 
> > dmesg | grep "power_save blacklist"
> > 
> > You should see a message like this:
> > 
> > "device 1458:a002 is on the power_save blacklist, forcing power_save to 0"
> > 
> 
> I booted kernel 4.17.9-200.fc28.x86_64 and I don't see any such message in
> dmesg. Further, 

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/pci/hda/hda_intel.c

Shows:

"ALSA: hda: Add Gigabyte P55A-UD3 and Z87-D3HP to the power_save blacklist"

Which does not list your motherboard, but your motherboard uses the same subsys ids for the audio part.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/pci/hda/hda_intel.c?h=v4.17

Does not list this, so it looks like you need to wait for the 4.18 kernel to become available in the Fedora updates repo.

I the mean time adding "snd_hda_intel.power_save=0" to your kernel commandline can be used to work around this.

> I have reported the bug here in any case: 
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=200687

Ok, I've closed that bug since there already is a fix for this in the upcoming 4.18 kernel.

(In reply to Hans de Goede from comment #94)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/
> pci/hda/hda_intel.c
> 
> Shows:
> 
> "ALSA: hda: Add Gigabyte P55A-UD3 and Z87-D3HP to the power_save blacklist"
> 
> Which does not list your motherboard, but your motherboard uses the same
> subsys ids for the audio part.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/
> pci/hda/hda_intel.c?h=v4.17
> 
> Does not list this, so it looks like you need to wait for the 4.18 kernel to
> become available in the Fedora updates repo.
> 
> I the mean time adding "snd_hda_intel.power_save=0" to your kernel
> commandline can be used to work around this.
> 
> > I have reported the bug here in any case: 
> > 
> > https://bugzilla.kernel.org/show_bug.cgi?id=200687
> 
> Ok, I've closed that bug since there already is a fix for this in the
> upcoming 4.18 kernel.


OK, great, thank you!

This is happening on a new install of F28

4.18.9-200.fc28.x86_64

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

Fixes the issue

An obviously the more permanent solution is above. Is there a way to make this fix easier on those who might not know how to run problems like this down?

(In reply to Donny Davis from comment #96)
> This is happening on a new install of F28
> 
> 4.18.9-200.fc28.x86_64
> 
> echo 0 > /sys/module/snd_hda_intel/parameters/power_save
> 
> Fixes the issue
> 
> An obviously the more permanent solution is above. Is there a way to make
> this fix easier on those who might not know how to run problems like this
> down?

What hardware are you seeing this on?

Please run alsa-info.sh, let is save it results to a file, rename that file to something like : alsa-info-vendor-boardtype.txt and attach that file here.

Created attachment 1489100 [details]
alsa-info for Dell Precision T3600

Running F27 for a long time now on an Intel DZ77BH, and this clicking just started very recently, an update must have triggered it I assume.  Running 4.18.12-100.fc27.x86_64 currently.  Turning off the power_save fixes it.

Created attachment 1493116 [details]
alsa-info for Intel DZ77BH

The most interesting part is nearly all of my equipment has intel based gear and this is the only machine that has the issue

I have 7 different dell precision+latitude laptops, none of which have this issue.

Donny, Bob, thank you for the provided info.

I've written a patch adding the vendor+product ids of your models to intel_hda driver's power_save blacklist and submitted this patch to the upstream kernel.

This should eventually trickle down into the Fedora kernels, so that power-saving will be automatically disabled on your models. In the mean time you can keep using the snd_hda_intel.power_save option to disable this manually.

Created attachment 1504860 [details]
alsa-info for ASRock N68C-S UCC

ASRock N68C-S UCC have this issue too. Here is alsa-info.sh attachment.

(In reply to Ivan Rybakov from comment #103)
> Created attachment 1504860 [details]
> alsa-info for ASRock N68C-S UCC
> 
> ASRock N68C-S UCC have this issue too. Here is alsa-info.sh attachment.

To be clear, with "this issue" you mean clicks / plopping noises which go away when you specify snd_hda_intel.power_save=0 on the kernel commandline, right?

(In reply to Hans de Goede from comment #104)
> To be clear, with "this issue" you mean clicks / plopping noises which go
> away when you specify snd_hda_intel.power_save=0 on the kernel commandline,
> right?

Yes. I searched about this strange noises yesterday, found this bug ticket and workaround, which worked for me. I read comments, saw about blacklisting models with sound power save problem, and attached alsa-info for my model.

(In reply to Ivan Rybakov from comment #105)
> (In reply to Hans de Goede from comment #104)
> > To be clear, with "this issue" you mean clicks / plopping noises which go
> > away when you specify snd_hda_intel.power_save=0 on the kernel commandline,
> > right?
> 
> Yes. I searched about this strange noises yesterday, found this bug ticket
> and workaround, which worked for me. I read comments, saw about blacklisting
> models with sound power save problem, and attached alsa-info for my model.

OK, thank you for the bug report.

I've send a patch permanently adding your model motherboard to the blacklist upstream. This should eventually trickle down into the Fedora kernels. In the mean time you can keep using the workaround.

Created attachment 1519028 [details]
alsa-info-Apple-MacPro3,1.txt

On a Mac Pro (early 2008) the sound clicks/pops, which stops when specifying snd_hda_intel.power_save=0 on the kernel commandline. Attached is the alsa-info for this computer.

Created attachment 1519075 [details]
Alsa-info for Dell Latitude 7480

Hi,

I found this bug, but I don't know if I have the same bug. I have attached alsa-info, this is with standard powersaving ON.

I have a Dell Latitude 7480 (with Realtek ALC3246) and I get the popping/clicking all the time with the speakers (NOT on headphones). I have tried snd_hda_intel.power_save=0 and snd_hda_intel.power_save_controller=N and verified that powersaving is off, and I still get the popping everytime whem audio starts playing and when audio is playing and a silent moment comes (for example watching a video and the speaker turns off his/her mic). I even get multiple pops/clicks when I test the speaker channel on the Gnome sound settings panel.

I am on Fedora 29 and kernel 4.19.13-300.fc29.x86_64.

I have been trying to solve this for a long time, and whatever I try, it doesn't help.

Did some more digging around..and found the following.

After doing snd_hda_intel.power_save=0 and snd_hda_intel.power_save_controller=N and verifying that powersaving is off, I still get the popping/clicking. So I tried a pure Jack setup (and killed pulsaudio and masked its services/socket). With a pure Jack setup (so no pulseaudio sink) there is no clicking/popping anymore. So the problem must be pulseaudio I figured.

Then I came accros the module "module-suspend-on-idle" that is loaded with /etc/pulse/default.pa and /etc/pulse/system.pa. I first tried commenting it and then tried unloading it, there were still the same pops/clicks. Maybe it the clicks were caused by samplerate conversion or something else. Then I found out than this module has a timeout setting. 

So now I have "load module module-suspend-on-idle timeout=5" on both /etc/pulse/default.pa and /etc/pulse/system.pa and the clicks/pops are gone!

So it seems not every pop/click/crackle is the same :)

In my case (and maybe for others too) it comes down to the following:

1. With snd_hda_intel powersaving ON (also the controller), I get a faint pop when the soundcard turns ON and OFF and while the soundcard is on I hear a very slight electrical whine/hiss, this behaviour is totally OK and acceptable (and maybe even hardware related, or kernel related?), I don't mind this.

2. With snd_hda_intel powersaving ON of OFF I would still get several pops/clicks when doing short consecutive "bursts" of audio, for example testing the speaker channels in Gnome sounds settings and changing the volume produces ALOT of pops/clicks, listening to an audio/video podcast and the mic (of the person in the audio/video) being turned on or off or slight pauses in the audio, causes alot of pops/clicks. This behaviour is very annoying and until today I had not find a solution to this problem.

Now with "load module module-suspend-on-idle timeout=5" (or maybe even a lower timeout, I will test it further), problem 2 is gone! and "problem 1" is still there. I find this totally OK and will keep it this way.

So in conclusion, the above mentioned solution helped in my case, maybe this should be the default behaviour for this module. I will continue testing this.

Shall I open a new bug for this at Freedesktop bugzilla?

After some further testing I am totally confused....

The solution above does not work. I am now convinced this is (in my case) either a kernel/driver bug or maybe hardware.

I narrowed it down to something very simple. Rebooting/restarting my laptop causes these clicks/pops/crackle (problem nr.2), no matter what I do, even on a pure Jack config (with no pulseaudio running), there are these pops etc. BUT when I suspend and resume, there are no more pops and everything is ok. No tinkering or anything needed. 

In my case booting the machine and using it normally causes these issues. Only after resuming from suspend, the issues go away. So that leaves out hardware problems I think and maybe it is a kernel or driver issue?

I don't know what to do now, maybe open a bugreport at the kernel bugzilla

(In reply to Kadir from comment #110)
> I don't know what to do now, maybe open a bugreport at the kernel bugzilla

Yes file a bug at the kernel bugzilla and attach the output of the alsa-info.sh script there. You may also want to send an email to alsa-devel with the same contents as the bug, and point to the bug in the email, mentioning that the bug has the alsa-info.sh

Hi Frederik,

(In reply to Frederik Holden from comment #107)
> Created attachment 1519028 [details]
> alsa-info-Apple-MacPro3,1.txt

For some reason this file does not contain subsystem-id info for the soundcard. Maybe Apple does not use this ? Can you run:

lspci -v -nn -s '00:1b.0'

And copy and paste the output here ?

Regards,

Hans

(In reply to Hans de Goede from comment #112)
> Hi Frederik,
> 
> (In reply to Frederik Holden from comment #107)
> > Created attachment 1519028 [details]
> > alsa-info-Apple-MacPro3,1.txt
> 
> For some reason this file does not contain subsystem-id info for the
> soundcard. Maybe Apple does not use this ? Can you run:
> 
> lspci -v -nn -s '00:1b.0'
> 
> And copy and paste the output here ?
> 
> Regards,
> 
> Hans

00:1b.0 Audio device [0403]: Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09)
	Flags: bus master, fast devsel, latency 0, IRQ 37
	Memory at 94004000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Capabilities: [130] Root Complex Link
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

(In reply to Frederik Holden from comment #113)
> 00:1b.0 Audio device [0403]: Intel Corporation 631xESB/632xESB High
> Definition Audio Controller [8086:269a] (rev 09)
> 	Flags: bus master, fast devsel, latency 0, IRQ 37
> 	Memory at 94004000 (64-bit, non-prefetchable) [size=16K]
> 	Capabilities: [50] Power Management version 2
> 	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
> 	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
> 	Capabilities: [100] Virtual Channel
> 	Capabilities: [130] Root Complex Link
> 	Kernel driver in use: snd_hda_intel
> 	Kernel modules: snd_hda_intel

Thank you for the quick response. So here is what this looks like normally:

00:1f.3 Audio device [0403]: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller [8086:a170] (rev 31)
        Subsystem: ASRock Incorporation Device [1849:5892]
        Flags: bus master, fast devsel, latency 32, IRQ 135
        Memory at df140000 (64-bit, non-prefetchable) [size=16K]
        Memory at df120000 (64-bit, non-prefetchable) [size=64K]
        Capabilities: <access denied>
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

Notice the "Subsystem" entry, so it looks like Apple has not set any Subsystem ids on this device (why oh why). I did not even know that was possible with PCI devices :| Without these ids which define the vendor and product-id of the motherboard I cannot add an entry for this device to the blacklist.

So you will have to keep using snd_hda_intel.power_save=0 as a workaround, sorry.

(In reply to Hans de Goede from comment #114)
> Notice the "Subsystem" entry, so it looks like Apple has not set any
> Subsystem ids on this device (why oh why). I did not even know that was
> possible with PCI devices :| Without these ids which define the vendor and
> product-id of the motherboard I cannot add an entry for this device to the
> blacklist.
> 
> So you will have to keep using snd_hda_intel.power_save=0 as a workaround,
> sorry.

That's odd. Almost every other PCI device on the system has a subsystem entry.

Thanks for the help anyway, I guess I'll stick to the workaround.

@Kadir

Do you have tuned running? 
In my case tuned was changing the parameters no matter what I put on the kernel command line. 
I am running on a workstation, so power isn't really an issue for me. I changed it to the throughput-performance mode and the right parameter was loaded into 
cat /sys/module/snd_hda_intel/parameters/power_save
0

Check this parameter after a reboot and ensure it didn't flip back to 10

@Donny

Thanks for helping out. I don't run tuned. I used to run TLP, but I found that I dont't need it anymore with Fedora 29.

The situation is still the same even with kernel 4.20

I've install Fedora 30 on my desktop and am having the popping issue. Basically every time I reboot I have to run this command. It's really annoying.

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

I was running PopOS and was able to fix the problem by completing this:

vim /etc/modprobe.d/alsa-base.conf

options snd-hda-intel power_save=0 power_save_controller=N

However, alsa-base.conf file does not exist in that directory in Fedora.

Here is my output from the alsa-info.sh script:

http://alsa-project.org/db/?f=3c8a396b0cc5f6c2f047dd9e472365e41e44bc0e

Please see comment #3.

And yes, this clicking noises are still present in fedora 31.

"pass snd_hda_intel.power_save=0 on the kernel command line" from comment #3.

What does that mean? Is that updating grub and placing that there at boot up?

If so, that's more of a workaround, right? When would this be permanently fix? Is that a kernel fix or an upstream Alsa fix?

The kernel switches the sound card off by default to save power. Only in use, it is turned on. The following command tells the kernel to not turn it off: 

$ sudo grubby --update-kernel=ALL --args='snd_hda_intel.power_save=0' 

This info will simply be added to the boot parameter.

If you want to remove the parameter use:

$ sudo grubby --update-kernel=ALL --remove-args='snd_hda_intel.power_save=0'

Finally got a chance to try this out.

It seems grubby command doesn't work in Fedora.

Let me be more specific:

It seems grubby command doesn't work in Fedora 31.

Researching...

I have this (sound) problem too and grubby just work as it should.

Created attachment 1645218 [details]
alsa info for Asrock Z77 Pro3

I seeing this issue on F31. Disabling power saving seems to fix it, however I'm now seeing an issue where for a significant amount of time after booting, I get no audio at all. Then there's a click and then the audio starts working again.

Actually scratch that last bit. That seems to be happening even after I remove the power saving disabling bit from my kernel line. I must just not have noticed it before, and it never happened on Xubuntu.

This bug also affects the following hardware, with a slightly different symptoms:

00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
        Subsystem: CLEVO/KAPOK Computer Device 6504
        Flags: bus master, fast devsel, latency 0, IRQ 34
        Memory at f7e14000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

00:03.0 0403: 8086:0c0c (rev 06)
        Subsystem: 1558:6504
        Flags: bus master, fast devsel, latency 0, IRQ 34
        Memory at f7e14000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
        Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
        Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
        Kernel driver in use: snd_hda_intel
        Kernel modules: snd_hda_intel

With this hardware, this bug simply clips off the first 400-500ms (approx) of audio when it starts playing initially. Playing audio again after a brief delay is unaffected. After some period of time without any audio playing, the next audio playback has its initial 400-500ms clipped again.

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

This fixes this bug.

(In reply to Sam Varshavchik from comment #129)
> This bug also affects the following hardware, with a slightly different
> symptoms:
> 
> 00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core
> Processor HD Audio Controller (rev 06)
>         Subsystem: CLEVO/KAPOK Computer Device 6504
>         Flags: bus master, fast devsel, latency 0, IRQ 34
>         Memory at f7e14000 (64-bit, non-prefetchable) [size=16K]
>         Capabilities: [50] Power Management version 2
>         Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit-
>         Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
>         Kernel driver in use: snd_hda_intel
>         Kernel modules: snd_hda_intel

Thank you for reporting this, I've submitted a patch upstream wityh a quirk to automatically disable powersaving on your model laptop.

Created attachment 1681369 [details]
alsa-info for Clevo W650SJ

Also affected by issues related to audio power saving on my Clevo W650SJ laptop. Its model number is similar to that in comment 129, but I experiences a "common" popping/clicking sound when the playback begins, and a low-frequency humming noise in the earphone after it stops, with power_save=1. Those noise will be gone after passing power_save=0 to snd_hda_intel.

According to other sources on the Internet, this laptop uses a VIA VT1802S codec.
The output of alsa-info.sh is attached, and output of lspci -v -nn -s 00:1b.0 follows:

00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20] (rev 05)
	Subsystem: CLEVO/KAPOK Computer 8 Series/C220 Series Chipset High Definition Audio Controller [1558:6501]
	Flags: bus master, fast devsel, latency 0, IRQ 35
	Memory at f7a10000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: [50] Power Management version 2
	Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00
	Capabilities: [100] Virtual Channel
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

Created attachment 1684111 [details]
Lenovo E93Z AIO

Lenovo E93Z AIO. Constant crackling and popping with power management enabled. Disabling solves it.

e.g. opening a terminal and pressing tab will cause a beep, but with power management it will cause a pop/crackly, with a messed up beep, and a few moments later it will pop/crackle again when it puts the audio device again in power saving mode... very annoying.

alsa-info attached.