[alsa-devel] Audio crackles with 4.1-rc1
Takashi Iwai
tiwai at suse.de
Wed Jun 10 20:23:01 CEST 2015
At Wed, 10 Jun 2015 19:43:03 +0300,
Mihai Donțu wrote:
>
> On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote:
> > At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote:
> > > On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
> > > > At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
> > > > > At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
> > > > > > On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
> > > > > > > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
> > > > > > > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
> > > > > > > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
> > > > > > > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
> > > > > > > > > > > From: Takashi Iwai <tiwai at suse.de>
> > > > > > > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
> > > > > > > > > > >
> > > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click
> > > > > > > > > > > noises at transition from D3 to D0 when the widget power-saving is
> > > > > > > > > > > enabled. Further debugging session showed that avoiding it isn't
> > > > > > > > > > > trivial, unfortunately, since paths are basically activated
> > > > > > > > > > > dynamically while the pins have been already enabled.
> > > > > > > > > > >
> > > > > > > > > > > This patch disables the widget power-saving for such codecs.
> > > > > > > > > > >
> > > > > > > > > > > Reported-by: Jonathan McDowell <noodles at earth.li>
> > > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai at suse.de>
> > > > > > > > > > > ---
> > > > > > > > > > > sound/pci/hda/patch_realtek.c | 3 ++-
> > > > > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > > > > > > > > > index 2e246fe495f6..31f8f13be907 100644
> > > > > > > > > > > --- a/sound/pci/hda/patch_realtek.c
> > > > > > > > > > > +++ b/sound/pci/hda/patch_realtek.c
> > > > > > > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
> > > > > > > > > > >
> > > > > > > > > > > spec = codec->spec;
> > > > > > > > > > > spec->gen.shared_mic_vref_pin = 0x18;
> > > > > > > > > > > - codec->power_save_node = 1;
> > > > > > > > > > > + if (codec->core.vendor_id != 0x10ec0292)
> > > > > > > > > > > + codec->power_save_node = 1;
> > > > > > > > > > >
> > > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models,
> > > > > > > > > > > alc269_fixup_tbl, alc269_fixups);
> > > > > > > > > >
> > > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still
> > > > > > > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude
> > > > > > > > > > E7440):
> > > > > > > > > >
> > > > > > > > > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
> > > > > > > > > > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
> > > > > > > > > > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> > > > > > > > > > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0
> > > > > > > > > > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs:
> > > > > > > > > > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19
> > > > > > > > > > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a
> > > > > > > > > > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
> > > > > > > > > >
> > > > > > > > > > 4.0.4 was fine.
> > > > > > > > >
> > > > > > > > > Does it happen only once at boot (i.e. at power up), or happens always
> > > > > > > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't
> > > > > > > > > have much effect. Something else, very subtle thing, e.g. the order
> > > > > > > > > of verb execution, might cause this kind of problem.
> > > > > > > >
> > > > > > > > Only at power up. I've also suspend-resumed twice and can confirm it's
> > > > > > > > OK.
> > > > > > > >
> > > > > > > > There's a _very_ brief click at suspend (when the power is cut), but it
> > > > > > > > looks like a plain circuitry thing. I probably didn't notice it before
> > > > > > > > because I wasn't looking for it.
> > > > > > >
> > > > > > > Thanks. Do you get the same click noise when reloading snd-hda-intel
> > > > > > > driver? Also, does it happen when booting in runlevel 3?
> > > > > > >
> > > > > > > Last but not least, a patch like below has any effect?
> > > > > > >
> > > > > > >
> > > > > > > Takashi
> > > > > > >
> > > > > > > ---
> > > > > > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > > > > > > --- a/sound/pci/hda/hda_codec.c
> > > > > > > +++ b/sound/pci/hda/hda_codec.c
> > > > > > > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec,
> > > > > > > break;
> > > > > > > }
> > > > > > >
> > > > > > > + if (power_state == AC_PWRST_D0)
> > > > > > > + msleep(100);
> > > > > > > return state;
> > > > > > > }
> > > > > > >
> > > > > >
> > > > > > Reloading snd-hda-intel does not trigger the noise, but it helps. I've
> > > > > > noticed that the clicks appear when loading/reloading pulseaudio.
> > > > > >
> > > > > > $ pulseaudio -k
> > > > > >
> > > > > > will spawn a new child in background (probably asked by kmix) and
> > > > > > immediately I hear the noise. Reloading the driver makes the problem go
> > > > > > away.
> > > > >
> > > > > Hm. It's a bit inconsistent, but still this can be only at the full
> > > > > power up sequence.
> > > > >
> > > > > > telinit 3 does nothing for me (Gentoo seems to have things wired
> > > > > > differently). Manually reloading alsasound (/etc/init.d/alsasound) did
> > > > > > not trigger the problem either.
> > > > > >
> > > > > > However! Your patch seems to work. Cold boot, pulseaudio restart and
> > > > > > nothing. Not a peep. :-)
> > > > >
> > > > > OK, could you try to reduce the sleep value from 100 to 10?
> > > > > Does it still work?
> > > >
> > > > ... and check whether the patch below works instead. This is a better
> > > > place if it really fixes. The former patch is in the common path
> > > > every driver uses while this is codec-specific.
> > > >
> > > > ---
> > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > > index 0320cb523d9e..957412548ba1 100644
> > > > --- a/sound/pci/hda/patch_realtek.c
> > > > +++ b/sound/pci/hda/patch_realtek.c
> > > > @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
> > > >
> > > > spec = codec->spec;
> > > > spec->gen.shared_mic_vref_pin = 0x18;
> > > > - if (codec->core.vendor_id != 0x10ec0292)
> > > > + if (codec->core.vendor_id == 0x10ec0292)
> > > > + msleep(100); /* for avoiding click noise at power up */
> > > > + else
> > > > codec->power_save_node = 1;
> > > >
> > > > snd_hda_pick_fixup(codec, alc269_fixup_models,
> > >
> > > The initial patch but with msleep(10), works OK. This new one, however,
> > > does not (with 100ms or 10ms).
> >
> > Hmm, could you make sure that the sleep is actually called, e.g. by
> > adding a debug print or such? I blindly assumed that your codec is
> > as same as Joanathan's (vendor id 0x10ec0292). You can check
> > /proc/asound/card*/codec#* files, too.
>
> I added some printk-s:
>
> [Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: vendor_id: 0x10ec0292
> [Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: sleeping for 100ms
>
> The code above runs some good seconds before pulseaudio starts and
> triggers the clicks. Even before rootfs is re-mounted rw.
OK, then it's really needed to be right after the power transition.
To be sure, below is the patch I'm going to apply. If it really
works, please give you tested-by tag.
thanks,
Takashi
-- 8< --
From: Takashi Iwai <tiwai at suse.de>
Subject: [PATCH] ALSA: hda - Reduce click noise at power up
Some machines suffer from click noises at power up with the recent
kernels, and this seems triggered at the power transition and the
immediate verb executions. As a workaround, put a short delay (10ms)
right after the D0 transition.
There are a few places that have the same kind of delays, especially
in the resume path. I guess they can be removed (or reduced) after
this patch. But, since the delay is relatively small, let's do it
later as a cleanup.
Reported-by: Mihai Donțu <mihai.dontu at gmail.com>
Signed-off-by: Takashi Iwai <tiwai at suse.de>
---
sound/pci/hda/hda_codec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
index b7782212dd64..38f5509ee52f 100644
--- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -3077,6 +3077,9 @@ static unsigned int hda_set_power_state(struct hda_codec *codec,
break;
}
+ if (power_state == AC_PWRST_D0)
+ msleep(10);
+
return state;
}
--
2.4.3
More information about the Alsa-devel
mailing list