Bug 1525104 - Clicking noise when start or stop sound playing
Summary: Clicking noise when start or stop sound playing
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 27
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-12 15:46 UTC by David Horvath
Modified: 2019-02-02 11:38 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-12-18 18:51:51 UTC


Attachments (Terms of Use)
Recorded click with my phone (26.80 KB, audio/mpeg)
2017-12-12 16:03 UTC, David Horvath
no flags Details
output of lspci for ASRock MB (5.51 KB, text/plain)
2018-02-08 12:41 UTC, Alexandre Franke
no flags Details
lspci-asus-prime-x370-pro (22.32 KB, text/plain)
2018-02-10 08:13 UTC, Wolfgang Ulbrich
no flags Details
alsa-info asus prime x370-Pro (49.28 KB, text/plain)
2018-02-22 12:18 UTC, Wolfgang Ulbrich
no flags Details
alsa-info.sh for Acer Aspire 5930G (44.18 KB, text/plain)
2018-05-02 07:08 UTC, NSLW
no flags Details
alsa info (56.63 KB, text/plain)
2018-05-10 14:05 UTC, Riku Seppala
no flags Details
lspci -v -nn -s 00:1b.0 for Gigabyte GA-Z87X-UD3H (399 bytes, text/plain)
2018-05-11 16:14 UTC, Brandon Nielsen
no flags Details
alsa-info.sh --no-upload for Gigabyte GA-Z87X-UD3H (62.91 KB, text/plain)
2018-05-11 16:15 UTC, Brandon Nielsen
no flags Details
lspci -v -nn -s 00:1b.0 for Asrock H81M-HDS (573 bytes, text/plain)
2018-05-11 19:52 UTC, Brandon Nielsen
no flags Details
alsa-info.sh --no-upload for Asrock H81M-HDS (49.17 KB, text/plain)
2018-05-11 19:54 UTC, Brandon Nielsen
no flags Details
Test patch to change ALC882 codec shutup callback (387 bytes, patch)
2018-05-13 16:45 UTC, Takashi Iwai
no flags Details | Diff
alsa-info from Dell E7450 (45.53 KB, text/plain)
2018-05-23 14:11 UTC, Jason Scalia
no flags Details
Dell 7450 lspci -v -n Output (8.50 KB, text/plain)
2018-05-23 14:12 UTC, Jason Scalia
no flags Details
HP Omen 870 – 117 NS (6.30 KB, text/plain)
2018-06-10 22:13 UTC, Víctor R. Ruiz
no flags Details
Intel DQ35JO desktop motherboard lspci output (11.96 KB, text/plain)
2018-06-12 01:34 UTC, virtual8
no flags Details
alsa-info.txt.asrock.x399-pro-gaming (75.62 KB, text/plain)
2018-07-20 21:56 UTC, marc skinner
no flags Details
lspci.asrock.x399-pro-gaming (7.36 KB, text/plain)
2018-07-20 21:56 UTC, marc skinner
no flags Details
lspci output from Gigabyte H81M-DS2V system (10.20 KB, text/plain)
2018-07-30 17:34 UTC, Jonathan Underwood
no flags Details
alsa-info output for Gigabyte H81M-DS2V (59.32 KB, text/plain)
2018-07-30 17:35 UTC, Jonathan Underwood
no flags Details
alsa-info for Dell Precision T3600 (44.35 KB, text/plain)
2018-10-01 15:50 UTC, Donny Davis
no flags Details
alsa-info for Intel DZ77BH (53.64 KB, text/plain)
2018-10-12 05:17 UTC, Bob Farmer
no flags Details
alsa-info for ASRock N68C-S UCC (50.17 KB, text/plain)
2018-11-12 19:31 UTC, Ivan Rybakov
no flags Details
alsa-info-Apple-MacPro3,1.txt (41.25 KB, text/plain)
2019-01-07 14:36 UTC, Frederik Holden
no flags Details
Alsa-info for Dell Latitude 7480 (42.55 KB, text/plain)
2019-01-07 20:43 UTC, Kadir
no flags Details

Description David Horvath 2017-12-12 15:46:32 UTC
Description of problem:
After runned dnf update, I get a new version (11.1-6.fc27).
To my notebook is connected an external sound amplifier. Before dnf update was working fine, but after it have clicking noise if my notebook play a sound (in start and in end too).
Like when you turn it on the pc while amplifier turned on. Do you understand?
So I think the pulseaudio turn on and off my soundcard (for each sound being played).
My soundcard is: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller

This click noise destroys my speakers and my amplifier.


Version-Release number of selected component (if applicable):
11.1-6.fc27

How reproducible:
Play sound via external amplifier.

Steps to Reproduce:
1. connect external amplifier to notebook.
2. play sound and stop sound

Actual results:
Click noise in speaker.

Expected results:
Clean sound starting and stopping

Comment 1 David Horvath 2017-12-12 16:03:11 UTC
Created attachment 1366788 [details]
Recorded click with my phone

I recorded the clicks with my phone.

Comment 2 Riku Seppala 2017-12-13 16:21:56 UTC
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

Comment 3 Jeremy Cline 2017-12-13 18:06:49 UTC
Can you pass snd_hda_intel.power_save=0 on the kernel command line and see if that resolves your issue?

Thanks

Comment 4 Riku Seppala 2017-12-13 18:25:50 UTC
Yes, that seems to resolve this for me.

Comment 5 Hans de Goede 2017-12-14 12:09:31 UTC
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

Comment 6 Hans de Goede 2017-12-14 12:14:48 UTC
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.

Comment 7 Riku Seppala 2017-12-14 13:38:16 UTC
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.

Comment 8 Hans de Goede 2017-12-14 13:42:53 UTC
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 ?

Comment 9 Riku Seppala 2017-12-14 14:02:24 UTC
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.

Comment 10 Hans de Goede 2017-12-14 14:58:39 UTC
(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.

Comment 11 Riku Seppala 2017-12-14 15:01:31 UTC
(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.

Comment 12 Riku Seppala 2017-12-14 15:08:54 UTC
> 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.

Comment 13 Hans de Goede 2017-12-14 15:12:59 UTC
(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?

Comment 14 Riku Seppala 2017-12-14 15:58:34 UTC
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?

Comment 15 David Horvath 2017-12-14 17:09:44 UTC
Workaround is working with all of kernels, sound is clean:

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

Comment 16 Hans de Goede 2017-12-14 19:13:59 UTC
(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.

Comment 17 Hans de Goede 2017-12-14 19:15:51 UTC
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

Comment 18 Alexandre Franke 2017-12-14 19:20:59 UTC
(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.

Comment 19 Riku Seppala 2017-12-14 19:33:57 UTC
(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

Comment 20 Fedora Update System 2017-12-14 20:52:56 UTC
kernel-4.14.6-300.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-129969aa8a

Comment 21 Fedora Update System 2017-12-15 11:30:09 UTC
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

Comment 22 Fedora Update System 2017-12-15 14:30:55 UTC
kernel-4.14.6-200.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-ba6b6e71f7

Comment 23 Wolfgang Ulbrich 2017-12-15 17:40:27 UTC
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.

Comment 24 Fedora Update System 2017-12-16 11:24:25 UTC
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

Comment 25 Florian Kisser 2017-12-16 12:35:33 UTC
kernel-4.14.6-300.fc27.x86_64 fixed it for me

Comment 26 David Horvath 2017-12-16 19:39:43 UTC
Dell Latitude E5530

Comment 27 Aleksandar Kostadinov 2017-12-18 16:41:22 UTC
How can one see what the actual code change was? I don't see a link here.

Comment 28 Hans de Goede 2017-12-18 17:09:51 UTC
(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.

Comment 29 Fedora Update System 2017-12-18 18:51:51 UTC
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.

Comment 30 Fedora Update System 2017-12-19 21:36:53 UTC
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.

Comment 31 Hans de Goede 2018-01-30 11:15:20 UTC
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

Comment 32 Wolfgang Ulbrich 2018-02-04 16:33:49 UTC
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.

Comment 33 Hans de Goede 2018-02-07 10:36:59 UTC
(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.

Comment 34 Hans de Goede 2018-02-08 11:53:29 UTC
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.

Comment 35 Alexandre Franke 2018-02-08 12:41:23 UTC
Created attachment 1393169 [details]
output of lspci for ASRock MB

Comment 36 Wolfgang Ulbrich 2018-02-10 08:13:44 UTC
Created attachment 1394128 [details]
lspci-asus-prime-x370-pro

Comment 37 Hans de Goede 2018-02-22 12:04:52 UTC
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?

Comment 38 Wolfgang Ulbrich 2018-02-22 12:18:07 UTC
Created attachment 1399349 [details]
alsa-info asus prime x370-Pro

Comment 39 Hans de Goede 2018-02-22 12:30:49 UTC
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.

Comment 40 Hans de Goede 2018-02-22 13:11:10 UTC
Forget about that test-kernel please, it is no good. I will prepare a new one.

Comment 41 Hans de Goede 2018-02-22 13:27:01 UTC
A fixed test-build is now building here, please test once it is done:
https://koji.fedoraproject.org/koji/taskinfo?taskID=25235331

Comment 42 Wolfgang Ulbrich 2018-02-22 18:15:27 UTC
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

Comment 43 Hans de Goede 2018-02-22 18:56:38 UTC
(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.

Comment 44 NSLW 2018-05-02 07:08:09 UTC
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

Comment 45 Hans de Goede 2018-05-03 07:56:03 UTC
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

Comment 46 Viktor Ashirov 2018-05-03 14:13:06 UTC
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

Comment 47 Hans de Goede 2018-05-07 15:06:43 UTC
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

Comment 48 Hans de Goede 2018-05-08 07:35:51 UTC
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

Comment 49 Riku Seppala 2018-05-10 12:21:43 UTC
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

Comment 50 Hans de Goede 2018-05-10 13:35:17 UTC
(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?

Comment 51 Riku Seppala 2018-05-10 14:05:33 UTC
Created attachment 1434390 [details]
alsa info

Comment 52 Brandon Nielsen 2018-05-11 16:13:47 UTC
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.

Comment 53 Brandon Nielsen 2018-05-11 16:14:53 UTC
Created attachment 1435032 [details]
lspci -v -nn -s 00:1b.0 for Gigabyte GA-Z87X-UD3H

Comment 54 Brandon Nielsen 2018-05-11 16:15:36 UTC
Created attachment 1435033 [details]
alsa-info.sh --no-upload for Gigabyte GA-Z87X-UD3H

Comment 55 Brandon Nielsen 2018-05-11 17:05:34 UTC
I lied, motherboard is a Gigabyte Z87-D3HP with a Realtek ALC892 codec. The above attachments still apply.

Comment 56 Brandon Nielsen 2018-05-11 19:52:33 UTC
Created attachment 1435114 [details]
lspci -v -nn -s 00:1b.0 for Asrock H81M-HDS

Comment 57 Brandon Nielsen 2018-05-11 19:53:09 UTC
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.

Comment 58 Brandon Nielsen 2018-05-11 19:54:04 UTC
Created attachment 1435115 [details]
alsa-info.sh --no-upload for Asrock H81M-HDS

Comment 59 Takashi Iwai 2018-05-13 16:42:25 UTC
(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.

Comment 60 Takashi Iwai 2018-05-13 16:45:10 UTC
Created attachment 1435762 [details]
Test patch to change ALC882 codec shutup callback

Comment 61 Hans de Goede 2018-05-23 13:14:41 UTC
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

Comment 62 Hans de Goede 2018-05-23 13:27:14 UTC
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

Comment 63 Jason Scalia 2018-05-23 14:10:45 UTC
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

Comment 64 Jason Scalia 2018-05-23 14:11:43 UTC
Created attachment 1440639 [details]
alsa-info from Dell E7450

Comment 65 Jason Scalia 2018-05-23 14:12:31 UTC
Created attachment 1440640 [details]
Dell 7450 lspci -v -n Output

Comment 66 Jason Scalia 2018-05-23 14:13:29 UTC
(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

Comment 67 Hans de Goede 2018-05-23 18:05:29 UTC
(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)

Comment 68 Jason Scalia 2018-05-23 18:33:03 UTC
Thank you, opened up https://bugzilla.kernel.org/show_bug.cgi?id=199815

Comment 69 mst 2018-05-23 19:39:58 UTC
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.

Comment 70 Hans de Goede 2018-05-23 20:02:40 UTC
(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.

Comment 71 mst 2018-05-23 20:27:47 UTC
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."

Comment 72 Viktor Ashirov 2018-05-28 16:33:03 UTC
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!

Comment 73 Hans de Goede 2018-05-29 07:10:52 UTC
(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.

Comment 74 mst 2018-05-29 10:21:56 UTC
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.

Comment 75 Takashi Iwai 2018-05-29 12:56:52 UTC
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.

Comment 76 mst 2018-05-29 13:29:44 UTC
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.

Comment 77 Alexandre Franke 2018-05-29 20:39:23 UTC
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

Comment 78 Víctor R. Ruiz 2018-06-10 22:13:56 UTC
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.

Comment 79 virtual8 2018-06-12 01:34:22 UTC
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).

Comment 80 Hans de Goede 2018-06-12 08:01:08 UTC
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

Comment 81 Hans de Goede 2018-06-12 08:03:01 UTC
(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.

Comment 82 marc skinner 2018-07-20 21:53:58 UTC
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

Comment 83 marc skinner 2018-07-20 21:56:23 UTC
Created attachment 1469429 [details]
alsa-info.txt.asrock.x399-pro-gaming

Comment 84 marc skinner 2018-07-20 21:56:59 UTC
Created attachment 1469435 [details]
lspci.asrock.x399-pro-gaming

Comment 85 Steve 2018-07-22 04:31:33 UTC
For those who do not know, the right (workaround) command is:

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

Comment 86 Jonathan Underwood 2018-07-30 17:34:44 UTC
Created attachment 1471605 [details]
lspci output from Gigabyte H81M-DS2V system

Comment 87 Jonathan Underwood 2018-07-30 17:35:25 UTC
Created attachment 1471606 [details]
alsa-info output for Gigabyte H81M-DS2V

Comment 88 Jonathan Underwood 2018-07-30 17:36:11 UTC
Is this still the right way to report motherboards with this problem?

Comment 89 Hans de Goede 2018-08-02 11:55:04 UTC
(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.

Comment 90 Hans de Goede 2018-08-02 11:59:12 UTC
(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.

Comment 91 Hans de Goede 2018-08-02 12:05:14 UTC
(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.

Comment 92 Alexandre Franke 2018-08-02 15:15:08 UTC
(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!

Comment 93 Jonathan Underwood 2018-08-03 13:02:18 UTC
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

Comment 94 Hans de Goede 2018-08-04 10:49:24 UTC
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.

Comment 95 Jonathan Underwood 2018-08-04 16:11:58 UTC
(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!

Comment 96 Donny Davis 2018-10-01 11:05:25 UTC
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?

Comment 97 Hans de Goede 2018-10-01 11:09:08 UTC
(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.

Comment 98 Donny Davis 2018-10-01 15:50:49 UTC
Created attachment 1489100 [details]
alsa-info for Dell Precision T3600

Comment 99 Bob Farmer 2018-10-12 05:16:49 UTC
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.

Comment 100 Bob Farmer 2018-10-12 05:17:53 UTC
Created attachment 1493116 [details]
alsa-info for Intel DZ77BH

Comment 101 Donny Davis 2018-10-12 12:07:58 UTC
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.

Comment 102 Hans de Goede 2018-10-16 10:20:12 UTC
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.

Comment 103 Ivan Rybakov 2018-11-12 19:31:42 UTC
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.

Comment 104 Hans de Goede 2018-11-13 07:48:59 UTC
(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?

Comment 105 Ivan Rybakov 2018-11-13 07:58:47 UTC
(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.

Comment 106 Hans de Goede 2018-11-22 11:39:04 UTC
(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.

Comment 107 Frederik Holden 2019-01-07 14:36:06 UTC
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.

Comment 108 Kadir 2019-01-07 20:43:59 UTC
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.

Comment 109 Kadir 2019-01-08 09:30:30 UTC
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?

Comment 110 Kadir 2019-01-08 18:40:01 UTC
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

Comment 111 Hans de Goede 2019-01-08 21:59:36 UTC
(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@alsa-project.org with the same contents as the bug, and point to the bug in the email, mentioning that the bug has the alsa-info.sh

Comment 112 Hans de Goede 2019-01-11 08:58:37 UTC
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

Comment 113 Frederik Holden 2019-01-11 09:03:51 UTC
(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

Comment 114 Hans de Goede 2019-01-11 09:08:47 UTC
(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.

Comment 115 Frederik Holden 2019-01-11 09:24:57 UTC
(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.

Comment 116 Donny Davis 2019-01-29 13:52:35 UTC
@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

Comment 117 Kadir 2019-02-02 11:38:48 UTC
@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


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