Re: [alsa-devel] Audio crackles with 4.1-rc1
At Wed, 29 Apr 2015 12:28:59 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 04:43:00PM +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 15:05:20 +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 13:35:18 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 02:00:17PM +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 12:21:57 +0100, Jonathan McDowell wrote:
Having upgraded to 4.1-rc1 from 4.0 I'm now hearing audio crackles at regular intervals. I'm fairly sure this is due to the HDA power save as once audio is playing things are fine, it's just when starting to play audio that I hear the crackle.
System is a Dell Latitude E7240. I haven't tried a bisect yet but will attempt to find some time to do so in the next few days. It looks like there have been some changes in sound/hda/ between 4.0 + 4.1-rc1 so I'll concentrate on those first.
There are lots of code changes and enhancements wrt power saving in 4.1, and bisection won't help so much, I'm afraid.
First off, check the device status while you hear crackles. Is the codec in runtime suspend (aka power save)? This can be seen in /sys/bus/hdaudio/devices/*/power/runtime_status. Then check the runtime status of the controller, too, found in /sys/class/sound/card?/device/power/runtime_status.
The cracking is definitely happening with the transition from suspended to active:
/sys/class/sound/card0/device/power/runtime_status:suspended /sys/class/sound/card1/device/power/runtime_status:active /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status:suspended /sys/bus/hdaudio/devices/hdaudioC1D0/power/runtime_status:active
card1 + C1D0 were suspended, I hit delete in a terminal to force a terminal bell, got the crackle and the state changed to active as above.
Ah, so it's a click noise that happens only once per runtime PM transition? I thought it were constant crackling noises from your description ("regular intervals").
In anyway, please give alsa-info.sh output on both 4.0 and 4.1.
Also, does the click noise occur only at powering up, and not at powering down?
The click is only on the transition from suspended to active; not constantly during playback and not when transitioning from active to suspended. It doesn't appear 4.0 is doing the suspending at all; there are no /sys/bus/hdaudio/devices/*/power/runtime_status files and the card runtime_status is always active. alsa-info for 4.0 + 4.1-rc1 attached.
OK, thanks for clarification.
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Takashi
--- diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h index 2a8aa9dfb83d..8e47d9cc369f 100644 --- a/include/sound/hdaudio.h +++ b/include/sound/hdaudio.h @@ -79,6 +79,7 @@ struct hdac_device { bool lazy_cache:1; /* don't wake up for writes */ bool caps_overwriting:1; /* caps overwrite being in process */ bool cache_coef:1; /* cache COEF read/write too */ + bool cache_only:1; /* don't write actually registers */ };
/* device/driver type used for matching */ diff --git a/sound/hda/hdac_regmap.c b/sound/hda/hdac_regmap.c index 7371e0c3926f..c5b3dcbbacdd 100644 --- a/sound/hda/hdac_regmap.c +++ b/sound/hda/hdac_regmap.c @@ -265,6 +265,9 @@ static int hda_reg_write(void *context, unsigned int reg, unsigned int val) unsigned int verb; int i, bytes, err;
+ if (codec->cache_only) + return 0; + reg &= ~0x00080000U; /* drop GET bit */ reg |= (codec->addr << 28); verb = get_verb(reg); diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index e70a7fb393dd..8f79d649975b 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3156,28 +3156,29 @@ static void hda_call_codec_resume(struct hda_codec *codec) { atomic_inc(&codec->core.in_pm);
- if (codec->core.regmap) - regcache_mark_dirty(codec->core.regmap); - codec->power_jiffies = jiffies;
hda_set_power_state(codec, AC_PWRST_D0); restore_shutup_pins(codec); hda_exec_init_verbs(codec); snd_hda_jack_set_dirty_all(codec); + if (codec->core.regmap) { + regcache_mark_dirty(codec->core.regmap); + codec->core.cache_only = true; + } if (codec->patch_ops.resume) codec->patch_ops.resume(codec); - else { - if (codec->patch_ops.init) - codec->patch_ops.init(codec); - if (codec->core.regmap) - regcache_sync(codec->core.regmap); - } + else if (codec->patch_ops.init) + codec->patch_ops.init(codec);
if (codec->jackpoll_interval) hda_jackpoll_work(&codec->jackpoll_work.work); else snd_hda_jack_report_sync(codec); + if (codec->core.regmap) { + codec->core.cache_only = false; + regcache_sync(codec->core.regmap); + } atomic_dec(&codec->core.in_pm); }
diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 3d2597b7037b..844d5e6ae1a1 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -5780,8 +5780,6 @@ int snd_hda_gen_init(struct hda_codec *codec) /* call init functions of standard auto-mute helpers */ update_automute_all(codec);
- regcache_sync(codec->core.regmap); - if (spec->vmaster_mute.sw_kctl && spec->vmaster_mute.hook) snd_hda_sync_vmaster_hook(&spec->vmaster_mute);
diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 5f44f60a6389..e4a774ddb1fc 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2211,7 +2211,6 @@ static int generic_hdmi_resume(struct hda_codec *codec) int pin_idx;
codec->patch_ops.init(codec); - regcache_sync(codec->core.regmap);
for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) { struct hdmi_spec_per_pin *per_pin = get_pin(spec, pin_idx); diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b18b9c67b262..34219aa6a40e 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -799,7 +799,6 @@ static int alc_resume(struct hda_codec *codec) if (!spec->no_depop_delay) msleep(150); /* to avoid pop noise */ codec->patch_ops.init(codec); - regcache_sync(codec->core.regmap); hda_call_check_power_status(codec, 0x01); return 0; } @@ -3059,7 +3058,6 @@ static int alc269_resume(struct hda_codec *codec) msleep(200); }
- regcache_sync(codec->core.regmap); hda_call_check_power_status(codec, 0x01);
/* on some machine, the BIOS will clear the codec gpio data when enter
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
At Wed, 29 Apr 2015 12:28:59 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 04:43:00PM +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 15:05:20 +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 13:35:18 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 02:00:17PM +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 12:21:57 +0100, Jonathan McDowell wrote:
> Having upgraded to 4.1-rc1 from 4.0 I'm now hearing audio > crackles at regular intervals. I'm fairly sure this is due to > the HDA power save as once audio is playing things are fine, > it's just when starting to play audio that I hear the crackle. > > System is a Dell Latitude E7240. I haven't tried a bisect yet > but will attempt to find some time to do so in the next few > days. It looks like there have been some changes in sound/hda/ > between 4.0 + 4.1-rc1 so I'll concentrate on those first. > There are lots of code changes and enhancements wrt power saving in 4.1, and bisection won't help so much, I'm afraid.
First off, check the device status while you hear crackles. Is the codec in runtime suspend (aka power save)? This can be seen in /sys/bus/hdaudio/devices/*/power/runtime_status. Then check the runtime status of the controller, too, found in /sys/class/sound/card?/device/power/runtime_status.
The cracking is definitely happening with the transition from suspended to active:
/sys/class/sound/card0/device/power/runtime_status:suspended /sys/class/sound/card1/device/power/runtime_status:active /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status:suspended /sys/bus/hdaudio/devices/hdaudioC1D0/power/runtime_status:active
card1 + C1D0 were suspended, I hit delete in a terminal to force a terminal bell, got the crackle and the state changed to active as above.
Ah, so it's a click noise that happens only once per runtime PM transition? I thought it were constant crackling noises from your description ("regular intervals").
In anyway, please give alsa-info.sh output on both 4.0 and 4.1.
Also, does the click noise occur only at powering up, and not at powering down?
The click is only on the transition from suspended to active; not constantly during playback and not when transitioning from active to suspended. It doesn't appear 4.0 is doing the suspending at all; there are no /sys/bus/hdaudio/devices/*/power/runtime_status files and the card runtime_status is always active. alsa-info for 4.0 + 4.1-rc1 attached.
OK, thanks for clarification.
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
J.
At Thu, 30 Apr 2015 16:01:31 +0100, Jonathan McDowell wrote:
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
At Wed, 29 Apr 2015 12:28:59 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 04:43:00PM +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 15:05:20 +0200, Takashi Iwai wrote:
At Tue, 28 Apr 2015 13:35:18 +0100, Jonathan McDowell wrote:
On Tue, Apr 28, 2015 at 02:00:17PM +0200, Takashi Iwai wrote: > At Tue, 28 Apr 2015 12:21:57 +0100, > Jonathan McDowell wrote: > > > Having upgraded to 4.1-rc1 from 4.0 I'm now hearing audio > > crackles at regular intervals. I'm fairly sure this is due to > > the HDA power save as once audio is playing things are fine, > > it's just when starting to play audio that I hear the crackle. > > > > System is a Dell Latitude E7240. I haven't tried a bisect yet > > but will attempt to find some time to do so in the next few > > days. It looks like there have been some changes in sound/hda/ > > between 4.0 + 4.1-rc1 so I'll concentrate on those first. > > > There are lots of code changes and enhancements wrt power saving > in 4.1, and bisection won't help so much, I'm afraid. > > First off, check the device status while you hear crackles. Is > the codec in runtime suspend (aka power save)? This can be seen > in /sys/bus/hdaudio/devices/*/power/runtime_status. Then check > the runtime status of the controller, too, found in > /sys/class/sound/card?/device/power/runtime_status.
The cracking is definitely happening with the transition from suspended to active:
/sys/class/sound/card0/device/power/runtime_status:suspended /sys/class/sound/card1/device/power/runtime_status:active /sys/bus/hdaudio/devices/hdaudioC0D0/power/runtime_status:suspended /sys/bus/hdaudio/devices/hdaudioC1D0/power/runtime_status:active
card1 + C1D0 were suspended, I hit delete in a terminal to force a terminal bell, got the crackle and the state changed to active as above.
Ah, so it's a click noise that happens only once per runtime PM transition? I thought it were constant crackling noises from your description ("regular intervals").
In anyway, please give alsa-info.sh output on both 4.0 and 4.1.
Also, does the click noise occur only at powering up, and not at powering down?
The click is only on the transition from suspended to active; not constantly during playback and not when transitioning from active to suspended. It doesn't appear 4.0 is doing the suspending at all; there are no /sys/bus/hdaudio/devices/*/power/runtime_status files and the card runtime_status is always active. alsa-info for 4.0 + 4.1-rc1 attached.
OK, thanks for clarification.
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
Then please confirm that only power_save_node disablement suffices. This can be considered as the least change that can be put to 4.1-rc if no better fix is found.
thanks,
Takashi
On Thu, Apr 30, 2015 at 07:06:31PM +0200, Takashi Iwai wrote:
At Thu, 30 Apr 2015 16:01:31 +0100, Jonathan McDowell wrote:
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
Then please confirm that only power_save_node disablement suffices. This can be considered as the least change that can be put to 4.1-rc if no better fix is found.
Setting codec->power_save_node to 0 in patch_alc269 is sufficient; no noticeable cracking occurring.
J.
At Sat, 2 May 2015 16:05:13 +0100, Jonathan McDowell wrote:
On Thu, Apr 30, 2015 at 07:06:31PM +0200, Takashi Iwai wrote:
At Thu, 30 Apr 2015 16:01:31 +0100, Jonathan McDowell wrote:
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
Then please confirm that only power_save_node disablement suffices. This can be considered as the least change that can be put to 4.1-rc if no better fix is found.
Setting codec->power_save_node to 0 in patch_alc269 is sufficient; no noticeable cracking occurring.
Does the patch below have any improvement?
Takashi
--- diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 788f969b1a68..17147c2638f3 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -841,11 +841,19 @@ static hda_nid_t path_power_update(struct hda_codec *codec, else state = AC_PWRST_D3; if (!snd_hda_check_power_state(codec, nid, state)) { - snd_hda_codec_write(codec, nid, 0, + snd_hda_codec_read(codec, nid, 0, AC_VERB_SET_POWER_STATE, state); changed = nid; - if (state == AC_PWRST_D0) - snd_hdac_regmap_sync_node(&codec->core, nid); + if (state == AC_PWRST_D0) { + msleep(10); + /* all known codecs seem to be capable to handle + * widgets state even in D3, so far. + * if any new codecs need to restore the widget + * states after D0 transition, call the function + * below. + */ + /* snd_hdac_regmap_sync_node(&codec->core, nid); */ + } } } return changed;
On Tue, May 19, 2015 at 08:15:32AM +0200, Takashi Iwai wrote:
At Sat, 2 May 2015 16:05:13 +0100, Jonathan McDowell wrote:
On Thu, Apr 30, 2015 at 07:06:31PM +0200, Takashi Iwai wrote:
At Thu, 30 Apr 2015 16:01:31 +0100, Jonathan McDowell wrote:
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
Then please confirm that only power_save_node disablement suffices. This can be considered as the least change that can be put to 4.1-rc if no better fix is found.
Setting codec->power_save_node to 0 in patch_alc269 is sufficient; no noticeable cracking occurring.
Does the patch below have any improvement?
I still get a clicking on the standby -> active transition with the patch provided on top of 4.1-rc4.
J.
At Tue, 19 May 2015 17:19:11 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 08:15:32AM +0200, Takashi Iwai wrote:
At Sat, 2 May 2015 16:05:13 +0100, Jonathan McDowell wrote:
On Thu, Apr 30, 2015 at 07:06:31PM +0200, Takashi Iwai wrote:
At Thu, 30 Apr 2015 16:01:31 +0100, Jonathan McDowell wrote:
On Wed, Apr 29, 2015 at 01:54:57PM +0200, Takashi Iwai wrote:
One patch you can try (with or without power_save_node disablement) is below, it squashes the verb sequences at (runtime) PM resume as we did for 4.0. Let me know if this changes the behavior.
Patch alone has no effect. Patch with power_save_node disablement solves the problem. Didn't try power_save_node disablement without the patch.
Then please confirm that only power_save_node disablement suffices. This can be considered as the least change that can be put to 4.1-rc if no better fix is found.
Setting codec->power_save_node to 0 in patch_alc269 is sufficient; no noticeable cracking occurring.
Does the patch below have any improvement?
I still get a clicking on the standby -> active transition with the patch provided on top of 4.1-rc4.
OK, just to be sure, could you check whether changing msleep(10) to msleep(100) makes no difference? Also put a line like pr_info("XXX power up %x\n", nid); after msleep() call to see which nodes are powered up dynamically.
Takashi
On Tue, May 19, 2015 at 07:09:12PM +0200, Takashi Iwai wrote:
At Tue, 19 May 2015 17:19:11 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 08:15:32AM +0200, Takashi Iwai wrote:
Does the patch below have any improvement?
I still get a clicking on the standby -> active transition with the patch provided on top of 4.1-rc4.
OK, just to be sure, could you check whether changing msleep(10) to msleep(100) makes no difference? Also put a line like pr_info("XXX power up %x\n", nid); after msleep() call to see which nodes are powered up dynamically.
Increasing the delay, if anything, makes the crackle when powering up seem a little longer. dmesg log looks like:
[ 4206.075557] XXX power up 2 [ 4206.179671] XXX power up 14 [ 4206.291758] XXX power up 3
J.
At Tue, 19 May 2015 22:53:10 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 07:09:12PM +0200, Takashi Iwai wrote:
At Tue, 19 May 2015 17:19:11 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 08:15:32AM +0200, Takashi Iwai wrote:
Does the patch below have any improvement?
I still get a clicking on the standby -> active transition with the patch provided on top of 4.1-rc4.
OK, just to be sure, could you check whether changing msleep(10) to msleep(100) makes no difference? Also put a line like pr_info("XXX power up %x\n", nid); after msleep() call to see which nodes are powered up dynamically.
Increasing the delay, if anything, makes the crackle when powering up seem a little longer. dmesg log looks like:
[ 4206.075557] XXX power up 2 [ 4206.179671] XXX power up 14 [ 4206.291758] XXX power up 3
OK, so everything looks correct, but the codec (or the machine) seems leading to the noise when a branched path is activated while the pin was already powered up. Then let's disable the widget power-saving for these codecs.
Could you confirm that the patch below works?
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18; - codec->power_save_node = 1; + if (codec->core.vendor_id != 0x10ec0292) + codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
On Wed, May 20, 2015 at 07:01:12AM +0200, Takashi Iwai wrote:
At Tue, 19 May 2015 22:53:10 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 07:09:12PM +0200, Takashi Iwai wrote:
At Tue, 19 May 2015 17:19:11 +0100, Jonathan McDowell wrote:
On Tue, May 19, 2015 at 08:15:32AM +0200, Takashi Iwai wrote:
Does the patch below have any improvement?
I still get a clicking on the standby -> active transition with the patch provided on top of 4.1-rc4.
OK, just to be sure, could you check whether changing msleep(10) to msleep(100) makes no difference? Also put a line like pr_info("XXX power up %x\n", nid); after msleep() call to see which nodes are powered up dynamically.
Increasing the delay, if anything, makes the crackle when powering up seem a little longer. dmesg log looks like:
[ 4206.075557] XXX power up 2 [ 4206.179671] XXX power up 14 [ 4206.291758] XXX power up 3
OK, so everything looks correct, but the codec (or the machine) seems leading to the noise when a branched path is activated while the pin was already powered up. Then let's disable the widget power-saving for these codecs.
Could you confirm that the patch below works?
4.1-rc4 + patch below running all day without hearing any crackles. Sounds good to me.
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
--
J.
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Takashi
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
--- diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
+ if (power_state == AC_PWRST_D0) + msleep(100); return state; }
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
We've got reports that ALC3226 (a Dell variant of ALC292) gives click noises at transition from D3 to D0 when the widget power-saving is enabled. Further debugging session showed that avoiding it isn't trivial, unfortunately, since paths are basically activated dynamically while the pins have been already enabled.
This patch disables the widget power-saving for such codecs.
Reported-by: Jonathan McDowell noodles@earth.li Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/patch_realtek.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 2e246fe495f6..31f8f13be907 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- codec->power_save_node = 1;
if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
thanks,
Takashi
At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > From: Takashi Iwai tiwai@suse.de > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > noises at transition from D3 to D0 when the widget power-saving is > enabled. Further debugging session showed that avoiding it isn't > trivial, unfortunately, since paths are basically activated > dynamically while the pins have been already enabled. > > This patch disables the widget power-saving for such codecs. > > Reported-by: Jonathan McDowell noodles@earth.li > Signed-off-by: Takashi Iwai tiwai@suse.de > --- > sound/pci/hda/patch_realtek.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > index 2e246fe495f6..31f8f13be907 100644 > --- a/sound/pci/hda/patch_realtek.c > +++ b/sound/pci/hda/patch_realtek.c > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > spec = codec->spec; > spec->gen.shared_mic_vref_pin = 0x18; > - codec->power_save_node = 1; > + if (codec->core.vendor_id != 0x10ec0292) > + codec->power_save_node = 1; > > snd_hda_pick_fixup(codec, alc269_fixup_models, > alc269_fixup_tbl, alc269_fixups);
I'm on 4.1-rc7 which appears to contain this patch, however, I still get the audio artifacts (crackles) when I boot my laptop (Latitude E7440):
[ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
... and check whether the patch below works instead. This is a better place if it really fixes. The former patch is in the common path every driver uses while this is codec-specific.
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..957412548ba1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18; - if (codec->core.vendor_id != 0x10ec0292) + if (codec->core.vendor_id == 0x10ec0292) + msleep(100); /* for avoiding click noise at power up */ + else codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > From: Takashi Iwai tiwai@suse.de > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > noises at transition from D3 to D0 when the widget power-saving is > > enabled. Further debugging session showed that avoiding it isn't > > trivial, unfortunately, since paths are basically activated > > dynamically while the pins have been already enabled. > > > > This patch disables the widget power-saving for such codecs. > > > > Reported-by: Jonathan McDowell noodles@earth.li > > Signed-off-by: Takashi Iwai tiwai@suse.de > > --- > > sound/pci/hda/patch_realtek.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > index 2e246fe495f6..31f8f13be907 100644 > > --- a/sound/pci/hda/patch_realtek.c > > +++ b/sound/pci/hda/patch_realtek.c > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > spec = codec->spec; > > spec->gen.shared_mic_vref_pin = 0x18; > > - codec->power_save_node = 1; > > + if (codec->core.vendor_id != 0x10ec0292) > > + codec->power_save_node = 1; > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > alc269_fixup_tbl, alc269_fixups); > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > get the audio artifacts (crackles) when I boot my laptop (Latitude > E7440): > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > 4.0.4 was fine.
Does it happen only once at boot (i.e. at power up), or happens always at runtime PM? If it's a once-off boot thing, the patch shouldn't have much effect. Something else, very subtle thing, e.g. the order of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
... and check whether the patch below works instead. This is a better place if it really fixes. The former patch is in the common path every driver uses while this is codec-specific.
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..957412548ba1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
if (codec->core.vendor_id == 0x10ec0292)
msleep(100); /* for avoiding click noise at power up */else codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
The initial patch but with msleep(10), works OK. This new one, however, does not (with 100ms or 10ms).
At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > From: Takashi Iwai tiwai@suse.de > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > noises at transition from D3 to D0 when the widget power-saving is > > > enabled. Further debugging session showed that avoiding it isn't > > > trivial, unfortunately, since paths are basically activated > > > dynamically while the pins have been already enabled. > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > Reported-by: Jonathan McDowell noodles@earth.li > > > Signed-off-by: Takashi Iwai tiwai@suse.de > > > --- > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > > index 2e246fe495f6..31f8f13be907 100644 > > > --- a/sound/pci/hda/patch_realtek.c > > > +++ b/sound/pci/hda/patch_realtek.c > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > spec = codec->spec; > > > spec->gen.shared_mic_vref_pin = 0x18; > > > - codec->power_save_node = 1; > > > + if (codec->core.vendor_id != 0x10ec0292) > > > + codec->power_save_node = 1; > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > alc269_fixup_tbl, alc269_fixups); > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > E7440): > > > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) > > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 > > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: > > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > 4.0.4 was fine. > > Does it happen only once at boot (i.e. at power up), or happens always > at runtime PM? If it's a once-off boot thing, the patch shouldn't > have much effect. Something else, very subtle thing, e.g. the order > of verb execution, might cause this kind of problem.
Only at power up. I've also suspend-resumed twice and can confirm it's OK.
There's a _very_ brief click at suspend (when the power is cut), but it looks like a plain circuitry thing. I probably didn't notice it before because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
... and check whether the patch below works instead. This is a better place if it really fixes. The former patch is in the common path every driver uses while this is codec-specific.
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..957412548ba1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
if (codec->core.vendor_id == 0x10ec0292)
msleep(100); /* for avoiding click noise at power up */else codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
The initial patch but with msleep(10), works OK. This new one, however, does not (with 100ms or 10ms).
Hmm, could you make sure that the sleep is actually called, e.g. by adding a debug print or such? I blindly assumed that your codec is as same as Joanathan's (vendor id 0x10ec0292). You can check /proc/asound/card*/codec#* files, too.
Takashi
On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > From: Takashi Iwai tiwai@suse.de > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > enabled. Further debugging session showed that avoiding it isn't > > > > trivial, unfortunately, since paths are basically activated > > > > dynamically while the pins have been already enabled. > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > Reported-by: Jonathan McDowell noodles@earth.li > > > > Signed-off-by: Takashi Iwai tiwai@suse.de > > > > --- > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > --- a/sound/pci/hda/patch_realtek.c > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > > > spec = codec->spec; > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > - codec->power_save_node = 1; > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > + codec->power_save_node = 1; > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > alc269_fixup_tbl, alc269_fixups); > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > E7440): > > > > > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > > > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) > > > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 > > > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: > > > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > > > 4.0.4 was fine. > > > > Does it happen only once at boot (i.e. at power up), or happens always > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > have much effect. Something else, very subtle thing, e.g. the order > > of verb execution, might cause this kind of problem. > > Only at power up. I've also suspend-resumed twice and can confirm it's > OK. > > There's a _very_ brief click at suspend (when the power is cut), but it > looks like a plain circuitry thing. I probably didn't notice it before > because I wasn't looking for it.
Thanks. Do you get the same click noise when reloading snd-hda-intel driver? Also, does it happen when booting in runlevel 3?
Last but not least, a patch like below has any effect?
Takashi
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(100);}
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
... and check whether the patch below works instead. This is a better place if it really fixes. The former patch is in the common path every driver uses while this is codec-specific.
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..957412548ba1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
if (codec->core.vendor_id == 0x10ec0292)
msleep(100); /* for avoiding click noise at power up */else codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
The initial patch but with msleep(10), works OK. This new one, however, does not (with 100ms or 10ms).
Hmm, could you make sure that the sleep is actually called, e.g. by adding a debug print or such? I blindly assumed that your codec is as same as Joanathan's (vendor id 0x10ec0292). You can check /proc/asound/card*/codec#* files, too.
I added some printk-s:
[Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: vendor_id: 0x10ec0292 [Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: sleeping for 100ms
The code above runs some good seconds before pulseaudio starts and triggers the clicks. Even before rootfs is re-mounted rw.
At Wed, 10 Jun 2015 19:43:03 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote: > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote: > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote: > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote: > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote: > > > > > From: Takashi Iwai tiwai@suse.de > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click > > > > > noises at transition from D3 to D0 when the widget power-saving is > > > > > enabled. Further debugging session showed that avoiding it isn't > > > > > trivial, unfortunately, since paths are basically activated > > > > > dynamically while the pins have been already enabled. > > > > > > > > > > This patch disables the widget power-saving for such codecs. > > > > > > > > > > Reported-by: Jonathan McDowell noodles@earth.li > > > > > Signed-off-by: Takashi Iwai tiwai@suse.de > > > > > --- > > > > > sound/pci/hda/patch_realtek.c | 3 ++- > > > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c > > > > > index 2e246fe495f6..31f8f13be907 100644 > > > > > --- a/sound/pci/hda/patch_realtek.c > > > > > +++ b/sound/pci/hda/patch_realtek.c > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec) > > > > > > > > > > spec = codec->spec; > > > > > spec->gen.shared_mic_vref_pin = 0x18; > > > > > - codec->power_save_node = 1; > > > > > + if (codec->core.vendor_id != 0x10ec0292) > > > > > + codec->power_save_node = 1; > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models, > > > > > alc269_fixup_tbl, alc269_fixups); > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude > > > > E7440): > > > > > > > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line > > > > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0) > > > > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0) > > > > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0 > > > > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs: > > > > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19 > > > > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a > > > > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12 > > > > > > > > 4.0.4 was fine. > > > > > > Does it happen only once at boot (i.e. at power up), or happens always > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't > > > have much effect. Something else, very subtle thing, e.g. the order > > > of verb execution, might cause this kind of problem. > > > > Only at power up. I've also suspend-resumed twice and can confirm it's > > OK. > > > > There's a _very_ brief click at suspend (when the power is cut), but it > > looks like a plain circuitry thing. I probably didn't notice it before > > because I wasn't looking for it. > > Thanks. Do you get the same click noise when reloading snd-hda-intel > driver? Also, does it happen when booting in runlevel 3? > > Last but not least, a patch like below has any effect? > > > Takashi > > --- > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c > --- a/sound/pci/hda/hda_codec.c > +++ b/sound/pci/hda/hda_codec.c > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, > break; > } > > + if (power_state == AC_PWRST_D0) > + msleep(100); > return state; > } >
Reloading snd-hda-intel does not trigger the noise, but it helps. I've noticed that the clicks appear when loading/reloading pulseaudio.
$ pulseaudio -k
will spawn a new child in background (probably asked by kmix) and immediately I hear the noise. Reloading the driver makes the problem go away.
Hm. It's a bit inconsistent, but still this can be only at the full power up sequence.
telinit 3 does nothing for me (Gentoo seems to have things wired differently). Manually reloading alsasound (/etc/init.d/alsasound) did not trigger the problem either.
However! Your patch seems to work. Cold boot, pulseaudio restart and nothing. Not a peep. :-)
OK, could you try to reduce the sleep value from 100 to 10? Does it still work?
... and check whether the patch below works instead. This is a better place if it really fixes. The former patch is in the common path every driver uses while this is codec-specific.
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..957412548ba1 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
if (codec->core.vendor_id == 0x10ec0292)
msleep(100); /* for avoiding click noise at power up */else codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models,
The initial patch but with msleep(10), works OK. This new one, however, does not (with 100ms or 10ms).
Hmm, could you make sure that the sleep is actually called, e.g. by adding a debug print or such? I blindly assumed that your codec is as same as Joanathan's (vendor id 0x10ec0292). You can check /proc/asound/card*/codec#* files, too.
I added some printk-s:
[Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: vendor_id: 0x10ec0292 [Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: sleeping for 100ms
The code above runs some good seconds before pulseaudio starts and triggers the clicks. Even before rootfs is re-mounted rw.
OK, then it's really needed to be right after the power transition. To be sure, below is the patch I'm going to apply. If it really works, please give you tested-by tag.
thanks,
Takashi
-- 8< -- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition.
There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup.
Reported-by: Mihai Donțu mihai.dontu@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
+ if (power_state == AC_PWRST_D0) + msleep(10); + return state; }
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition.
There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup.
Reported-by: Mihai Donțu mihai.dontu@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(10);- return state;
}
I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following:
* on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely; * on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s.
At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition.
There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup.
Reported-by: Mihai Donțu mihai.dontu@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(10);- return state;
}
I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following:
- on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely;
- on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s.
OK, then the patch is no-go. We need a bit deeper analysis.
About the headphone problem: don't you get the same issue with 4.0.x? Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and after plugging the headphone, and attach the outputs. (Run the script with --no-upload option.)
thanks,
Takashi
On Thu, 11 Jun 2015 07:01:13 +0200 Takashi Iwai wrote:
At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition.
There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup.
Reported-by: Mihai Donțu mihai.dontu@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(10);- return state;
}
I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following:
- on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely;
- on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s.
OK, then the patch is no-go. We need a bit deeper analysis.
About the headphone problem: don't you get the same issue with 4.0.x? Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and after plugging the headphone, and attach the outputs. (Run the script with --no-upload option.)
No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh.
Thanks,
At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
On Thu, 11 Jun 2015 07:01:13 +0200 Takashi Iwai wrote:
At Thu, 11 Jun 2015 01:12:36 +0300, Mihai Donțu wrote:
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent kernels, and this seems triggered at the power transition and the immediate verb executions. As a workaround, put a short delay (10ms) right after the D0 transition.
There are a few places that have the same kind of delays, especially in the resume path. I guess they can be removed (or reduced) after this patch. But, since the delay is relatively small, let's do it later as a cleanup.
Reported-by: Mihai Donțu mihai.dontu@gmail.com Signed-off-by: Takashi Iwai tiwai@suse.de
sound/pci/hda/hda_codec.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c index b7782212dd64..38f5509ee52f 100644 --- a/sound/pci/hda/hda_codec.c +++ b/sound/pci/hda/hda_codec.c @@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec, break; }
- if (power_state == AC_PWRST_D0)
msleep(10);- return state;
}
I take back my previous observations. I was at work and did not have access to headphones (one of those days). Now I'm at home, it's 1 AM, very quiet, and I notice the following:
- on speakers: the click reproduces but with _very_ low amplitude; msleep(100) is unnoticeable, but msleep(10) is, barely;
- on headphones: the moment I plug them I hear a loud static sound (like an old, untuned AM radio). If I play something, the static disappears. If I pause, the static returns after ~15s.
OK, then the patch is no-go. We need a bit deeper analysis.
About the headphone problem: don't you get the same issue with 4.0.x? Please take alsa-info.sh outputs on both 4.0.x and 4.1 before and after plugging the headphone, and attach the outputs. (Run the script with --no-upload option.)
No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh.
Both are taken in different states (one is headphone plugged and another unplugged?). At best, take the snapshot in the same situation for comparison.
In anyway, below is another shot in dark. The white noise is possibly the ill side effect of analog loopback. But it's strange that this didn't happen on 4.0.x. And, it combines another black magic that worked for another Dell model. Let's see.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9d3e0fcb4326..cf46f6012ba4 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4522,6 +4522,8 @@ enum { ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6, ALC298_FIXUP_DELL1_MIC_NO_PRESENCE, + ALC292_FIXUP_DELL_E74, + ALC292_FIXUP_DISABLE_AAMIX, };
static const struct hda_fixup alc269_fixups[] = { @@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE }, + [ALC292_FIXUP_DISABLE_AAMIX] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_disable_aamix, + }, + [ALC292_FIXUP_DELL_E74] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_dell_xps13, + .chained = true, + .chain_id = ALC292_FIXUP_DISABLE_AAMIX + }, };
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z), + SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E74), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
On Fri, 12 Jun 2015 09:00:06 +0200 Takashi Iwai wrote:
At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh.
Both are taken in different states (one is headphone plugged and another unplugged?). At best, take the snapshot in the same situation for comparison.
In anyway, below is another shot in dark. The white noise is possibly the ill side effect of analog loopback. But it's strange that this didn't happen on 4.0.x. And, it combines another black magic that worked for another Dell model. Let's see.
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9d3e0fcb4326..cf46f6012ba4 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4522,6 +4522,8 @@ enum { ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6, ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
- ALC292_FIXUP_DELL_E74,
- ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = { @@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE },
- [ALC292_FIXUP_DISABLE_AAMIX] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_disable_aamix,- },
- [ALC292_FIXUP_DELL_E74] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_dell_xps13,.chained = true,.chain_id = ALC292_FIXUP_DISABLE_AAMIX- },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
- SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E74), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
Nice shot! It appears to work. :-) No clicks, no static.
I had to apply it by hand over 4.1-rc7, because the first two arrays look different in both it and -master. Anyway, I will play with it some more today see if anything else is broken.
Oh, and yes, the second state is without headphones on. I removed them without thinking when the noise started. Sorry about that.
Thanks!
At Fri, 12 Jun 2015 12:45:23 +0300, Mihai Donțu wrote:
On Fri, 12 Jun 2015 09:00:06 +0200 Takashi Iwai wrote:
At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh.
Both are taken in different states (one is headphone plugged and another unplugged?). At best, take the snapshot in the same situation for comparison.
In anyway, below is another shot in dark. The white noise is possibly the ill side effect of analog loopback. But it's strange that this didn't happen on 4.0.x. And, it combines another black magic that worked for another Dell model. Let's see.
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9d3e0fcb4326..cf46f6012ba4 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4522,6 +4522,8 @@ enum { ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6, ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
- ALC292_FIXUP_DELL_E74,
- ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = { @@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE },
- [ALC292_FIXUP_DISABLE_AAMIX] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_disable_aamix,- },
- [ALC292_FIXUP_DELL_E74] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_dell_xps13,.chained = true,.chain_id = ALC292_FIXUP_DISABLE_AAMIX- },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
- SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E74), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
Nice shot! It appears to work. :-) No clicks, no static.
Good to hear!
I had to apply it by hand over 4.1-rc7, because the first two arrays look different in both it and -master. Anyway, I will play with it some more today see if anything else is broken.
While we are at it: could you try to enable codec->power_save_node in patch_alc269() (while keeping the new patch)?
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5671,8 +5671,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18; - if (codec->core.vendor_id != 0x10ec0292) - codec->power_save_node = 1; + codec->power_save_node = 1;
#ifdef CONFIG_PM codec->patch_ops.suspend = alc269_suspend;
This was the workaround for Jonathan's machine, but maybe the new workaround is good enough. After changing this, try to enable the power save by writing like
echo 1 > /sys/module/snd_hda_intel/parameters/power_save
and start/stop playing something.
thanks,
Takashi
At Fri, 12 Jun 2015 12:09:55 +0200, Takashi Iwai wrote:
At Fri, 12 Jun 2015 12:45:23 +0300, Mihai Donțu wrote:
On Fri, 12 Jun 2015 09:00:06 +0200 Takashi Iwai wrote:
At Fri, 12 Jun 2015 01:23:18 +0300, Mihai Donțu wrote:
No, 4.0.5 and all previous kernels (>= 3.12) are OK. I have attached a small tarball with the two files produced by alsa-info.sh.
Both are taken in different states (one is headphone plugged and another unplugged?). At best, take the snapshot in the same situation for comparison.
In anyway, below is another shot in dark. The white noise is possibly the ill side effect of analog loopback. But it's strange that this didn't happen on 4.0.x. And, it combines another black magic that worked for another Dell model. Let's see.
Takashi
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 9d3e0fcb4326..cf46f6012ba4 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4522,6 +4522,8 @@ enum { ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6, ALC298_FIXUP_DELL1_MIC_NO_PRESENCE,
- ALC292_FIXUP_DELL_E74,
- ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = { @@ -5054,6 +5056,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC269_FIXUP_HEADSET_MODE },
- [ALC292_FIXUP_DISABLE_AAMIX] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_disable_aamix,- },
- [ALC292_FIXUP_DELL_E74] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_dell_xps13,.chained = true,.chain_id = ALC292_FIXUP_DISABLE_AAMIX- },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5066,6 +5078,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
- SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E74), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
Nice shot! It appears to work. :-) No clicks, no static.
Good to hear!
I had to apply it by hand over 4.1-rc7, because the first two arrays look different in both it and -master. Anyway, I will play with it some more today see if anything else is broken.
While we are at it: could you try to enable codec->power_save_node in patch_alc269() (while keeping the new patch)?
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5671,8 +5671,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;
- codec->power_save_node = 1;
#ifdef CONFIG_PM codec->patch_ops.suspend = alc269_suspend;
For your convenience, below is the combined patch for 4.1.
Jonathan, could you also try this patch and see whether you still get the noise?
thanks,
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..919051d92a0b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4515,6 +4515,8 @@ enum { ALC288_FIXUP_DELL_HEADSET_MODE, ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6, + ALC292_FIXUP_DELL_E7X, + ALC292_FIXUP_DISABLE_AAMIX, };
static const struct hda_fixup alc269_fixups[] = { @@ -5037,6 +5039,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC288_FIXUP_DELL1_MIC_NO_PRESENCE }, + [ALC292_FIXUP_DISABLE_AAMIX] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_disable_aamix, + }, + [ALC292_FIXUP_DELL_E7X] = { + .type = HDA_FIXUP_FUNC, + .v.func = alc_fixup_dell_xps13, + .chained = true, + .chain_id = ALC292_FIXUP_DISABLE_AAMIX + }, };
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5049,6 +5061,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z), + SND_PCI_QUIRK(0x1028, 0x05ca, "Dell Latitude E7240", ALC292_FIXUP_DELL_E7X), + SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E7X), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), @@ -5637,8 +5651,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18; - if (codec->core.vendor_id != 0x10ec0292) - codec->power_save_node = 1; + codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
On Fri, 12 Jun 2015 16:13:16 +0200 Takashi Iwai wrote:
For your convenience, below is the combined patch for 4.1.
Jonathan, could you also try this patch and see whether you still get the noise?
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 0320cb523d9e..919051d92a0b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4515,6 +4515,8 @@ enum { ALC288_FIXUP_DELL_HEADSET_MODE, ALC288_FIXUP_DELL1_MIC_NO_PRESENCE, ALC288_FIXUP_DELL_XPS_13_GPIO6,
- ALC292_FIXUP_DELL_E7X,
- ALC292_FIXUP_DISABLE_AAMIX,
};
static const struct hda_fixup alc269_fixups[] = { @@ -5037,6 +5039,16 @@ static const struct hda_fixup alc269_fixups[] = { .chained = true, .chain_id = ALC288_FIXUP_DELL1_MIC_NO_PRESENCE },
- [ALC292_FIXUP_DISABLE_AAMIX] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_disable_aamix,- },
- [ALC292_FIXUP_DELL_E7X] = {
.type = HDA_FIXUP_FUNC,.v.func = alc_fixup_dell_xps13,.chained = true,.chain_id = ALC292_FIXUP_DISABLE_AAMIX- },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = { @@ -5049,6 +5061,8 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1025, 0x0775, "Acer Aspire E1-572", ALC271_FIXUP_HP_GATE_MIC_JACK_E1_572), SND_PCI_QUIRK(0x1025, 0x079b, "Acer Aspire V5-573G", ALC282_FIXUP_ASPIRE_V5_PINS), SND_PCI_QUIRK(0x1028, 0x0470, "Dell M101z", ALC269_FIXUP_DELL_M101Z),
- SND_PCI_QUIRK(0x1028, 0x05ca, "Dell Latitude E7240", ALC292_FIXUP_DELL_E7X),
- SND_PCI_QUIRK(0x1028, 0x05cb, "Dell Latitude E7440", ALC292_FIXUP_DELL_E7X), SND_PCI_QUIRK(0x1028, 0x05da, "Dell Vostro 5460", ALC290_FIXUP_SUBWOOFER), SND_PCI_QUIRK(0x1028, 0x05f4, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE), SND_PCI_QUIRK(0x1028, 0x05f5, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE),
@@ -5637,8 +5651,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;
codec->power_save_node = 1;
snd_hda_pick_fixup(codec, alc269_fixup_models, alc269_fixup_tbl, alc269_fixups);
This patch works fine for me. You can add my Tested-by when you re-spin it for Linus and if Jonathan is happy as well.
Thank you!
On Fri, Jun 12, 2015 at 04:13:16PM +0200, Takashi Iwai wrote:
At Fri, 12 Jun 2015 12:09:55 +0200, Takashi Iwai wrote:
At Fri, 12 Jun 2015 12:45:23 +0300, Mihai Donțu wrote:
Nice shot! It appears to work. :-) No clicks, no static.
Good to hear!
I had to apply it by hand over 4.1-rc7, because the first two arrays look different in both it and -master. Anyway, I will play with it some more today see if anything else is broken.
While we are at it: could you try to enable codec->power_save_node in patch_alc269() (while keeping the new patch)?
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5671,8 +5671,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;
- codec->power_save_node = 1;
#ifdef CONFIG_PM codec->patch_ops.suspend = alc269_suspend;
For your convenience, below is the combined patch for 4.1.
Jonathan, could you also try this patch and see whether you still get the noise?
Applying the combined patch to 4.1-rc7 I'm not getting any noise on the transition from suspended to active.
J.
At Sun, 14 Jun 2015 13:24:20 +0100, Jonathan McDowell wrote:
On Fri, Jun 12, 2015 at 04:13:16PM +0200, Takashi Iwai wrote:
At Fri, 12 Jun 2015 12:09:55 +0200, Takashi Iwai wrote:
At Fri, 12 Jun 2015 12:45:23 +0300, Mihai Donțu wrote:
Nice shot! It appears to work. :-) No clicks, no static.
Good to hear!
I had to apply it by hand over 4.1-rc7, because the first two arrays look different in both it and -master. Anyway, I will play with it some more today see if anything else is broken.
While we are at it: could you try to enable codec->power_save_node in patch_alc269() (while keeping the new patch)?
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -5671,8 +5671,7 @@ static int patch_alc269(struct hda_codec *codec)
spec = codec->spec; spec->gen.shared_mic_vref_pin = 0x18;
- if (codec->core.vendor_id != 0x10ec0292)
codec->power_save_node = 1;
- codec->power_save_node = 1;
#ifdef CONFIG_PM codec->patch_ops.suspend = alc269_suspend;
For your convenience, below is the combined patch for 4.1.
Jonathan, could you also try this patch and see whether you still get the noise?
Applying the combined patch to 4.1-rc7 I'm not getting any noise on the transition from suspended to active.
Great, I queued the fix patch for 4.1-final now.
thanks,
Takashi
participants (3)
-
Jonathan McDowell -
Mihai Donțu -
Takashi Iwai