Bug 112611

I have the same laptop with the same problem on the same kernel version. Whenever the loud pop occurs, the following gets logged: 

haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

I'm guessing this indicates that some firmware gets loaded when the audio hardware gets powered up. Like Tim, I have tried disabling powersaving in the snd_hda_intel module.

Note that in I2S mode, it's driven by a completely different driver.  Thus specifying options to snd-hda-intel doesn't influence on the behavior at all.

The symptom appears like an issue related with the audio resume path including the firmware loading, indeed.  I poked Intel people, so let's see whether they can find a workaround.

Related I2S audio bug in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1313434

It looks like the pop is coming as part of the RTD3 resume path. Can someone stop audio for > 5 seconds (in order for the driver to enter RTD3) and then play silence. i.e. aplay -f dat /dev/zero. Does the pop still occur.

Can someone also attach the alsa state file when the pop occurs too.

Created attachment 210821 [details]
Louds pops when starting/stopping playback of silence

Pops recorded when running
sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero
The hum only occurs when recording, not when listening through headphones.

Created attachment 210831 [details]
Louds pops when starting/stopping playback of speaker-test

Recording of running
for n in {1..3}; do speaker-test -c2 -t wav -l 1; sleep 1; done
The hum only occurs when recording, not when using headphones.

Created attachment 210841 [details]
Louds pops when skipping/searching inside a youtube video

Playback of a youtube video. When skipping inside the video, the playback stops/resumes, causing very loud noises.

Created attachment 210851 [details]
alsa state file

I've made a recording using an external, handheld recording device plugged into the headphone jack of the laptop. It's a recording of running

sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero

(I don't know the origin of the hum but I can't seem to prevent it when recording from the headphone jack. There's no hum when only using headphones.) 

The pops still occur. It doesn't matter how long playback has stopped for the pops to occur - they are immediate.

This is especially gruesome when skipping/searching. I've made a second recording of a youtube video, where I skip inside the track a couple of times, and every time there is a loud pop and even some other sound artifacts.

I've attached 3 recordings and the alsa state file.

Note that I had none of these problems in HDA mode.

Created attachment 239391 [details]
A patch to fix this issue.

A patch that brings fixups from HDA driver to ASoC driver.

This should fix the background click noise, lower the ear-hurting crack sound to a tolerable pop sound.

(In reply to Kai-Heng Feng from comment #10)
> Created attachment 239391 [details]
> A patch to fix this issue.
> 
> A patch that brings fixups from HDA driver to ASoC driver.
> 
> This should fix the background click noise, lower the ear-hurting crack
> sound to a tolerable pop sound.

Thank you for working on the problem.
Unfortunately I still have the clicking noise on the headphone with Kernel 4.8.4 and your patch on top. 
I also get these messages:
[   20.291156] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[   42.020556] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19
[   85.081136] haswell-pcm-audio haswell-pcm-audio: FW loaded, mailbox readback FW info: type 01, - version: 00.00, build 77, source commit id: 876ac6906f31a43b6772b23c7c983ce9dcb18a19

(In reply to David Weber from comment #11)
> Thank you for working on the problem.
> Unfortunately I still have the clicking noise on the headphone with Kernel
> 4.8.4 and your patch on top. 

Is it a XPS 9343? This patch applies to it exclusively.

(In reply to Kai-Heng Feng from comment #12)
> Is it a XPS 9343? This patch applies to it exclusively.

Yes:
	Manufacturer: Dell Inc.
	Product Name: XPS 13 9343

Kernel config also contains
# CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set
and I did a few cold boots

(In reply to David Weber from comment #13)
> (In reply to Kai-Heng Feng from comment #12)
> > Is it a XPS 9343? This patch applies to it exclusively.
> 
> Yes:
>       Manufacturer: Dell Inc.
>       Product Name: XPS 13 9343
> 
> Kernel config also contains
> # CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set
> and I did a few cold boots

Sorry for the late reply.

Can you add some code trace (pr_warn or printk) and see if this section of code is executed:

if (dmi_check_system(dmi_dell_dino))
	regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);

Because HDA driver does exactly the same thing, if this does not work on I2S mode, HDA mode will have the same issue too.

*Replicate*

Audible clicks only when starting the application and intermittently so:

$ mplayer filename.flac && sleep 1 && mplayer filename.flac && mplayer filename.flac

Then:

$ mplayer filename.flac
$ sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero

Sometimes this will click on mplayer and aplay.

But if I repeat the aplay line:

$ sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero
$ sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero
$ sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero
$ sleep 3; aplay -f dat -d 3 /dev/zero; sleep 7; aplay -f dat 3 /dev/zero
etc.

There are no clicks until I play a song with mplayer (or other audio program).

The clicks did not happen with PulseAudio, though there were clipping issues with PulseAudio that prompted me to uninstall it.

Aside from the click on starting mplayer (and other audio programs), Alsa works perfectly.

---


$ sudo alsa force-reload
Unloading ALSA sound driver modules: snd-seq-midi snd-seq-midi-event snd-seq snd-rawmidi snd-seq-device snd-hda-codec-hdmi snd-hda-codec-realtek snd-hda-codec-generic snd-hda-intel snd-hda-codec snd-hda-core snd-hwdep snd-pcm snd-timer (failed: modules still loaded: snd-hda-codec-hdmi snd-hda-codec-realtek snd-hda-codec-generic snd-hda-intel snd-hda-codec snd-hda-core snd-hwdep snd-pcm snd-timer).
Loading ALSA sound driver modules: snd-seq-midi snd-seq-midi-event snd-seq snd-rawmidi snd-seq-device snd-hda-codec-hdmi snd-hda-codec-realtek snd-hda-codec-generic snd-hda-intel snd-hda-codec snd-hda-core snd-hwdep snd-pcm snd-timer.

$ tail -2 /etc/modprobe.d/alsa-base.conf
options snd-hda-intel power_save=0 power_save_controller=N
options snd-hda-intel probe_mask=1 model=auto

$ uname -a
Linux server 4.8.4-040804-generic #201610220733 SMP Sat Oct 22 11:35:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

$ cat /etc/issue
Ubuntu 16.04.1 LTS \n \l

$ lspci | grep -i audio
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] SBx00 Azalia (Intel HDA)
01:00.1 Audio device: NVIDIA Corporation GK107 HDMI Audio Controller (rev a1)

$ amixer
Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined
  Playback channels: Mono
  Limits: Playback 0 - 64
  Mono: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]
Simple mixer control 'Front',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 64
  Mono:
  Front Left: Playback 64 [100%] [0.00dB] [on]
  Front Right: Playback 64 [100%] [0.00dB] [on]
Simple mixer control 'Line',0
  Capabilities: pvolume pswitch
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 31
  Mono:
  Front Left: Playback 1 [3%] [-33.00dB] [on]
  Front Right: Playback 1 [3%] [-33.00dB] [on]

$ pactl list
The program 'pactl' is currently not installed. You can install it by typing:
sudo apt install pulseaudio-utils

$ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC887-VD Analog [ALC887-VD Analog]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: SB [HDA ATI SB], device 1: ALC887-VD Digital [ALC887-VD Digital]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 1: NVidia [HDA NVidia], device 8: HDMI 2 [HDMI 2]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

$ cat /proc/asound/cards 
 0 [SB             ]: HDA-Intel - HDA ATI SB
                      HDA ATI SB at 0xfe024000 irq 16
 1 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xfcffc000 irq 19

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

$ tail -n+7 /usr/lib/pm-utils/power.d/intel-audio-powersave | head -2
#INTEL_AUDIO_POWERSAVE=${INTEL_AUDIO_POWERSAVE:-true}
INTEL_AUDIO_POWERSAVE=false

One of the following files was changed (as mentioned in my previous comment):

  /usr/lib/pm-utils/power.d/intel-audio-powersave
  /etc/modprobe.d/modpobe.conf

I rebooted and now the problem seems to have disappeared.

$ cat /etc/modprobe.d/modpobe.conf 
options snd_hda_intel model=auto power_save=0

Wrote too soon. The clicking issue continues to plague the system, intermittently.

(In reply to Kai-Heng Feng from comment #14)
> Can you add some code trace (pr_warn or printk) and see if this section of
> code is executed:
> 
> if (dmi_check_system(dmi_dell_dino))
>       regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);
> 
> Because HDA driver does exactly the same thing, if this does not work on I2S
> mode, HDA mode will have the same issue too.

I added a printk which gets executed but still have the popping-noise on the sound-jack after audio stops.
In HDA mode everything is fine.

I don't understand much about the driver but I saw this in
patch_realtek.c in alc_fixup_dell_xps13
case HDA_FIXUP_ACT_PRE_PROBE:
		/* mic pin 0x19 must be initialized with Vref Hi-Z, otherwise
		 * it causes a click noise at start up
		 */
		snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);

I didn't find the equivalent for i2s. Could this the culprit?

(In reply to David Weber from comment #18)
> (In reply to Kai-Heng Feng from comment #14)
> > Can you add some code trace (pr_warn or printk) and see if this section of
> > code is executed:
> > 
> > if (dmi_check_system(dmi_dell_dino))
> >     regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);
> > 
> > Because HDA driver does exactly the same thing, if this does not work on
> I2S
> > mode, HDA mode will have the same issue too.
> 
> I added a printk which gets executed but still have the popping-noise on the
> sound-jack after audio stops.
> In HDA mode everything is fine.

There are two issues here this patch tries to solve:
1. The constant background clicking sound, this should be totally gone,
2. Ear-hurting cracking sound before/after playing a sound, this patch can only alleviate it a bit. The cracking sound is still there but becomes be bearable.

Which case is it?

> 
> I don't understand much about the driver but I saw this in
> patch_realtek.c in alc_fixup_dell_xps13
> case HDA_FIXUP_ACT_PRE_PROBE:
>               /* mic pin 0x19 must be initialized with Vref Hi-Z, otherwise
>                * it causes a click noise at start up
>                */
>               snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
> 
> I didn't find the equivalent for i2s. Could this the culprit?

I wrote this patch a long time ago, so I totally forget how I came up with those numbers, let's check again:

soc/codecs/rt286.h
138 #define RT286_MIC1_DET_CTRL 0x19

sound/pci/hda/hda_local.h
462 #define PIN_VREFHIZ             (AC_PINCTL_IN_EN | AC_PINCTL_VREF_HIZ)

include/sound/hda_verbs.h
395 #define AC_PINCTL_IN_EN                 (1<<5)
390 #define AC_PINCTL_VREF_HIZ              0       /* Hi-Z */
...which makes PIN_VREFHIZ 0x20.

So,
  regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020)
should be equivalent to
  snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ)

(In reply to Kai-Heng Feng from comment #19)
> (In reply to David Weber from comment #18)
> > (In reply to Kai-Heng Feng from comment #14)
> > > Can you add some code trace (pr_warn or printk) and see if this section
> of
> > > code is executed:
> > > 
> > > if (dmi_check_system(dmi_dell_dino))
> > >   regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);
> > > 
> > > Because HDA driver does exactly the same thing, if this does not work on
> I2S
> > > mode, HDA mode will have the same issue too.
> > 
> > I added a printk which gets executed but still have the popping-noise on
> the
> > sound-jack after audio stops.
> > In HDA mode everything is fine.
> 
> There are two issues here this patch tries to solve:
> 1. The constant background clicking sound, this should be totally gone,
> 2. Ear-hurting cracking sound before/after playing a sound, this patch can
> only alleviate it a bit. The cracking sound is still there but becomes be
> bearable.
> 
> Which case is it?

I just had some interesting findings

Without your patch:
- Very heavy cracking before and after playing audio
- After audio plying immediately loud background clicking

With your patch:
- cracking before and after plying is much quieter
- The background clicking starts around 5 seconds after plying audio. It is also much quieter and has a very high tone. The interesting thing is that I can only hear it with my rather expensive headphones (Sennheiser HD 598). With some very cheap earphones I hear nothing.
The 5 second delay made me suspect powermanagement. I tried to modify the  pmdown_time parameter from snd_soc_core but it didn't change anything. Is there anything else with a 5 second timeout?

To sum it up your patch does improve the situation a lot.

> 
> > 
> > I don't understand much about the driver but I saw this in
> > patch_realtek.c in alc_fixup_dell_xps13
> > case HDA_FIXUP_ACT_PRE_PROBE:
> >             /* mic pin 0x19 must be initialized with Vref Hi-Z, otherwise
> >              * it causes a click noise at start up
> >              */
> >             snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
> > 
> > I didn't find the equivalent for i2s. Could this the culprit?
> 
> I wrote this patch a long time ago, so I totally forget how I came up with
> those numbers, let's check again:
> 
> soc/codecs/rt286.h
> 138 #define RT286_MIC1_DET_CTRL 0x19
> 
> sound/pci/hda/hda_local.h
> 462 #define PIN_VREFHIZ             (AC_PINCTL_IN_EN | AC_PINCTL_VREF_HIZ)
> 
> include/sound/hda_verbs.h
> 395 #define AC_PINCTL_IN_EN                 (1<<5)
> 390 #define AC_PINCTL_VREF_HIZ              0       /* Hi-Z */
> ...which makes PIN_VREFHIZ 0x20.
> 
> So,
>   regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020)
> should be equivalent to
>   snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ)

sorry, I missed that....

(In reply to David Weber from comment #20)
> (In reply to Kai-Heng Feng from comment #19)
> > (In reply to David Weber from comment #18)
> > > (In reply to Kai-Heng Feng from comment #14)
> > > > Can you add some code trace (pr_warn or printk) and see if this section
> of
> > > > code is executed:
> > > > 
> > > > if (dmi_check_system(dmi_dell_dino))
> > > >         regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);
> > > > 
> > > > Because HDA driver does exactly the same thing, if this does not work
> on I2S
> > > > mode, HDA mode will have the same issue too.
> > > 
> > > I added a printk which gets executed but still have the popping-noise on
> the
> > > sound-jack after audio stops.
> > > In HDA mode everything is fine.
> > 
> > There are two issues here this patch tries to solve:
> > 1. The constant background clicking sound, this should be totally gone,
> > 2. Ear-hurting cracking sound before/after playing a sound, this patch can
> > only alleviate it a bit. The cracking sound is still there but becomes be
> > bearable.
> > 
> > Which case is it?
> 
> I just had some interesting findings
> 
> Without your patch:
> - Very heavy cracking before and after playing audio
> - After audio plying immediately loud background clicking
> 
> With your patch:
> - cracking before and after plying is much quieter
> - The background clicking starts around 5 seconds after plying audio. It is
> also much quieter and has a very high tone. The interesting thing is that I
> can only hear it with my rather expensive headphones (Sennheiser HD 598).
> With some very cheap earphones I hear nothing.

My headphone bundles with iPhone 5 definitely belongs to the "cheap" category =)

> The 5 second delay made me suspect powermanagement. I tried to modify the 
> pmdown_time parameter from snd_soc_core but it didn't change anything. Is
> there anything else with a 5 second timeout?

Well, I have no clue on how ASoC works, but here's my finding:

I thinks the 5 seconds you observed is correct:
soc-core.c|66 col 12| static int pmdown_time = 5000;

Guess this is why setting the module parameter does not work:
intel/boards/broadwell.c|214 col 11| .ignore_pmdown_time = 1,

My XPS 9343 is not at my side right now,so I can only guess even more:
snd_soc_runtime_ignore_pmdown_time() returns false, hence it runs this code section instead:

 699                 } else {           
 700                         /* start delayed pop wq here for playback streams */               
 701                         rtd->pop_wait = 1;
 702                         queue_delayed_work(system_power_efficient_wq,                                                
 703                                            &rtd->delayed_work,
 704                                            msecs_to_jiffies(rtd->pmdown_time));            
 705                 }
... and that where the 5 seconds click sound come from.

So maybe this is the correct solution for all symptoms:
diff --git a/sound/soc/codecs/rt286.c b/sound/soc/codecs/rt286.c
index 9c365a7f758d..c9fa39a8bd55 100644
--- a/sound/soc/codecs/rt286.c
+++ b/sound/soc/codecs/rt286.c
@@ -1053,6 +1053,7 @@ static struct snd_soc_codec_driver soc_codec_dev_rt286 = {
        .resume = rt286_resume,
        .set_bias_level = rt286_set_bias_level,
        .idle_bias_off = true,
+       .ignore_pmdown_time = true,
        .component_driver = {
                .controls               = rt286_snd_controls,
                .num_controls           = ARRAY_SIZE(rt286_snd_controls),

If it's not working, just try making snd_soc_runtime_ignore_pmdown_time() returns true all the time.

> 
> To sum it up your patch does improve the situation a lot.

Good to know this is helpful. If setting .ignore_pmdown_time on the codec does not help, I'll try upstreaming the original patch.

> 
> > 
> > > 
> > > I don't understand much about the driver but I saw this in
> > > patch_realtek.c in alc_fixup_dell_xps13
> > > case HDA_FIXUP_ACT_PRE_PROBE:
> > >           /* mic pin 0x19 must be initialized with Vref Hi-Z, otherwise
> > >            * it causes a click noise at start up
> > >            */
> > >           snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ);
> > > 
> > > I didn't find the equivalent for i2s. Could this the culprit?
> > 
> > I wrote this patch a long time ago, so I totally forget how I came up with
> > those numbers, let's check again:
> > 
> > soc/codecs/rt286.h
> > 138 #define RT286_MIC1_DET_CTRL 0x19
> > 
> > sound/pci/hda/hda_local.h
> > 462 #define PIN_VREFHIZ             (AC_PINCTL_IN_EN | AC_PINCTL_VREF_HIZ)
> > 
> > include/sound/hda_verbs.h
> > 395 #define AC_PINCTL_IN_EN                 (1<<5)
> > 390 #define AC_PINCTL_VREF_HIZ              0       /* Hi-Z */
> > ...which makes PIN_VREFHIZ 0x20.
> > 
> > So,
> >   regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020)
> > should be equivalent to
> >   snd_hda_codec_set_pin_target(codec, 0x19, PIN_VREFHIZ)
> 
> sorry, I missed that....

(In reply to Kai-Heng Feng from comment #21)
> (In reply to David Weber from comment #20)
> > (In reply to Kai-Heng Feng from comment #19)
> > > (In reply to David Weber from comment #18)
> > > > (In reply to Kai-Heng Feng from comment #14)
> > > > > Can you add some code trace (pr_warn or printk) and see if this
> section of
> > > > > code is executed:
> > > > > 
> > > > > if (dmi_check_system(dmi_dell_dino))
> > > > >       regmap_write(rt286->regmap, RT286_MIC1_DET_CTRL, 0x0020);
> > > > > 
> > > > > Because HDA driver does exactly the same thing, if this does not work
> on I2S
> > > > > mode, HDA mode will have the same issue too.
> > > > 
> > > > I added a printk which gets executed but still have the popping-noise
> on the
> > > > sound-jack after audio stops.
> > > > In HDA mode everything is fine.
> > > 
> > > There are two issues here this patch tries to solve:
> > > 1. The constant background clicking sound, this should be totally gone,
> > > 2. Ear-hurting cracking sound before/after playing a sound, this patch
> can
> > > only alleviate it a bit. The cracking sound is still there but becomes be
> > > bearable.
> > > 
> > > Which case is it?
> > 
> > I just had some interesting findings
> > 
> > Without your patch:
> > - Very heavy cracking before and after playing audio
> > - After audio plying immediately loud background clicking
> > 
> > With your patch:
> > - cracking before and after plying is much quieter
> > - The background clicking starts around 5 seconds after plying audio. It is
> > also much quieter and has a very high tone. The interesting thing is that I
> > can only hear it with my rather expensive headphones (Sennheiser HD 598).
> > With some very cheap earphones I hear nothing.
> 
> My headphone bundles with iPhone 5 definitely belongs to the "cheap"
> category =)
> 
> > The 5 second delay made me suspect powermanagement. I tried to modify the 
> > pmdown_time parameter from snd_soc_core but it didn't change anything. Is
> > there anything else with a 5 second timeout?
> 
> Well, I have no clue on how ASoC works, but here's my finding:
> 
> I thinks the 5 seconds you observed is correct:
> soc-core.c|66 col 12| static int pmdown_time = 5000;
> 
> Guess this is why setting the module parameter does not work:
> intel/boards/broadwell.c|214 col 11| .ignore_pmdown_time = 1,
> 
> My XPS 9343 is not at my side right now,so I can only guess even more:
> snd_soc_runtime_ignore_pmdown_time() returns false, hence it runs this code
> section instead:
> 
>  699                 } else {           
>  700                         /* start delayed pop wq here for playback
> streams */               
>  701                         rtd->pop_wait = 1;
>  702                         queue_delayed_work(system_power_efficient_wq,  
> 
>  703                                            &rtd->delayed_work,
>  704                                           
> msecs_to_jiffies(rtd->pmdown_time));            
>  705                 }
> ... and that where the 5 seconds click sound come from.
> 
> So maybe this is the correct solution for all symptoms:
> diff --git a/sound/soc/codecs/rt286.c b/sound/soc/codecs/rt286.c
> index 9c365a7f758d..c9fa39a8bd55 100644
> --- a/sound/soc/codecs/rt286.c
> +++ b/sound/soc/codecs/rt286.c
> @@ -1053,6 +1053,7 @@ static struct snd_soc_codec_driver soc_codec_dev_rt286
> = {
>         .resume = rt286_resume,
>         .set_bias_level = rt286_set_bias_level,
>         .idle_bias_off = true,
> +       .ignore_pmdown_time = true,
>         .component_driver = {
>                 .controls               = rt286_snd_controls,
>                 .num_controls           = ARRAY_SIZE(rt286_snd_controls),
> 
> If it's not working, just try making snd_soc_runtime_ignore_pmdown_time()
> returns true all the time.

This 5 second delay was unfortunately a red herring :(
Nothing of the above worked. Eventually I disabled pulseaudio and the clicking started immediately after audio plying (through alsa directly) finished. Enabling pulseaudio with a higher log level reveals why this happens:

Sink alsa_output.platform-broadwell-audio.HiFi__hw_broadwellrt286__sink becomes idle, timeout in 5 seconds.

5 seconds after this message shows up the clicking also starts.

> 
> > 
> > To sum it up your patch does improve the situation a lot.
> 
> Good to know this is helpful. If setting .ignore_pmdown_time on the codec
> does not help, I'll try upstreaming the original patch.
> 
Good idea.

Hi all, any progress on the patch? I found it seems that the patch also works for Thinkpad Helix 2 for fixing the loud crack sound (after I committed out the dell_dino "if" statement). It will be great to upstream this patch.

Can you test when do PMU and PMD events get triggered?
Maintainer is not comfortable about what I see on my machine [1].

So we need to confirm what I saw is not a single case.

[1] http://mailman.alsa-project.org/pipermail/alsa-devel/2017-March/118929.html