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.
Hopefully relevant dmesg output for the device:
[ 23.551075] snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
[ 23.551279] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops 0xffffffff81891a00)
[ 23.575852] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
[ 23.575855] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
[ 23.575857] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
[ 23.575858] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0
[ 23.575859] snd_hda_codec_realtek hdaudioC1D0: inputs:
[ 23.575861] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19
[ 23.575863] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a
[ 23.575870] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
[ 23.582324] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input12
[ 23.582397] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.0/sound/card0/input13
[ 23.582747] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.0/sound/card0/input14
[ 23.593267] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9
[ 23.594102] input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input15
[ 23.594268] input: HDA Intel PCH Dock Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input16
[ 23.594346] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input17
I have:
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=600
set in my kernel config. There's no dmesg output around the times when
the crackling is occurring.
J.
--
Friends are God's apology for relations.
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.
>
> Hopefully relevant dmesg output for the device:
>
> [ 23.551075] snd_hda_intel 0000:00:03.0: enabling device (0000 -> 0002)
> [ 23.551279] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops 0xffffffff81891a00)
> [ 23.575852] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
> [ 23.575855] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
> [ 23.575857] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> [ 23.575858] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0
> [ 23.575859] snd_hda_codec_realtek hdaudioC1D0: inputs:
> [ 23.575861] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19
> [ 23.575863] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a
> [ 23.575870] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
> [ 23.582324] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input12
> [ 23.582397] input: HDA Intel HDMI HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:03.0/sound/card0/input13
> [ 23.582747] input: HDA Intel HDMI HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:03.0/sound/card0/input14
> [ 23.593267] input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/sound/card1/input9
> [ 23.594102] input: HDA Intel PCH Dock Mic as /devices/pci0000:00/0000:00:1b.0/sound/card1/input15
> [ 23.594268] input: HDA Intel PCH Dock Line Out as /devices/pci0000:00/0000:00:1b.0/sound/card1/input16
> [ 23.594346] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card1/input17
>
> I have:
>
> CONFIG_SND_HDA_POWER_SAVE_DEFAULT=600
>
> set in my kernel config. There's no dmesg output around the times when
> the crackling is occurring.
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.
And, take alsa-info.sh output snapshot while the noise. Run the
script with --no-upload option and attach the output file. Also, take
alsa-info.sh output on 4.0 kernel for comparison, too. At best, take
a snapshot in the similar situation (in power save, etc).
The possibly affecting change was the support of widget power saving.
For disabling it, try to comment out the line
codec->power_save_node = 1;
in patch_alc269() in sound/pci/hda/patch_realtek.c.
Takashi
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.
> And, take alsa-info.sh output snapshot while the noise. Run the
> script with --no-upload option and attach the output file. Also, take
> alsa-info.sh output on 4.0 kernel for comparison, too. At best, take
> a snapshot in the similar situation (in power save, etc).
Unfortunately the crackle is really very brief so it's difficult to
catch it in the act. I've attached the alsa-info.sh output from when
the above is reporting suspended and then when it's reporting active.
> The possibly affecting change was the support of widget power saving.
> For disabling it, try to comment out the line
> codec->power_save_node = 1;
> in patch_alc269() in sound/pci/hda/patch_realtek.c.
I'll try this out but it's probably going to be at least tomorrow before
I have time.
J.
--
xmpp:[email protected]
101 things you can't have too much of : 10
- CDs.
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.
Takashi
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?
Takashi
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.
J.
--
If this isn't war, why is CNN massing on the border?
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.
--
This .sig brought to you by the letter M and the number 7
Product of the Republic of HuggieTag
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.
--
Beware of programmers carrying screwdrivers.
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.
--
101 things you can't have too | .''`. Debian GNU/Linux Developer
much of : 9 - Processing power. | : :' : Happy to accept PGP signed
| `. `' or encrypted mail - RSA
| `- key on the keyservers.
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.
--
xmpp:[email protected]
"f u cn rd ths, u cn gt a gd jb n cmptr
prgrmmng." -- Simon
Cozens, ox.os.linux
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
---
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);
--
2.4.1
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Takashi Iwai <[email protected]>
> ---
> 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.
--
] http://www.earth.li/~noodles/ [] Sex, truth and jellibabies. [
] PGP/GPG Key @ the.earth.li [] [
] via keyserver, web or email. [] [
] RSA: 4096/2DA8B985 [] [
On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
> From: Takashi Iwai <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Takashi Iwai <[email protected]>
> ---
> 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.
--
Mihai Donțu
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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: Takashi Iwai <[email protected]>
> > ---
> > 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 <[email protected]>
> > > 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 <[email protected]>
> > > Signed-off-by: Takashi Iwai <[email protected]>
> > > ---
> > > 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.
--
Mihai Donțu
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 <[email protected]>
> > > > 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 <[email protected]>
> > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > ---
> > > > 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 <[email protected]>
> > > > > 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 <[email protected]>
> > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > ---
> > > > > 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.
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. :-)
--
Mihai Donțu
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 <[email protected]>
> > > > > > 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 <[email protected]>
> > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > ---
> > > > > > 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?
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 <[email protected]>
> > > > > > > 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 <[email protected]>
> > > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > > ---
> > > > > > > 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.
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 <[email protected]>
> > > > > > > > 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 <[email protected]>
> > > > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > > > ---
> > > > > > > > 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).
--
Mihai Donțu
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 <[email protected]>
> > > > > > > > > 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 <[email protected]>
> > > > > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > > > > ---
> > > > > > > > > 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.
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 <[email protected]>
> > > > > > > > > > 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 <[email protected]>
> > > > > > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > > > > > ---
> > > > > > > > > > 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.
--
Mihai Donțu
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 <[email protected]>
> > > > > > > > > > > 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 <[email protected]>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > > > > > > > > ---
> > > > > > > > > > > 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
---
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;
}
--
2.4.3
On Wed, 10 Jun 2015 20:23:01 +0200 Takashi Iwai wrote:
> From: Takashi Iwai <[email protected]>
> 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 <[email protected]>
> Signed-off-by: Takashi Iwai <[email protected]>
> ---
> 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.
--
Mihai Donțu
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 <[email protected]>
> > 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 <[email protected]>
> > Signed-off-by: Takashi Iwai <[email protected]>
> > ---
> > 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 <[email protected]>
> > > 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 <[email protected]>
> > > Signed-off-by: Takashi Iwai <[email protected]>
> > > ---
> > > 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,
--
Mihai Donțu
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 <[email protected]>
> > > > 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 <[email protected]>
> > > > Signed-off-by: Takashi Iwai <[email protected]>
> > > > ---
> > > > 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!
--
Mihai Donțu
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!
--
Mihai Donțu
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.
--
101 things you can't have too | .''`. Debian GNU/Linux Developer
much of : 47 - More coffee. | : :' : Happy to accept PGP signed
| `. `' or encrypted mail - RSA
| `- key on the keyservers.
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