From: "Mihai Donțu" <mihai.dontu@gmail.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Jonathan McDowell <noodles@earth.li>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: Audio crackles with 4.1-rc1
Date: Wed, 10 Jun 2015 19:43:03 +0300 [thread overview]
Message-ID: <20150610194303.3b82609d@mdontu-l.dsd.bitdefender.biz> (raw)
In-Reply-To: <s5hr3pjleac.wl-tiwai@suse.de>
On Wed, 10 Jun 2015 18:27:23 +0200 Takashi Iwai wrote:
> At Wed, 10 Jun 2015 19:22:02 +0300, Mihai Donțu wrote:
> > On Wed, 10 Jun 2015 14:50:30 +0200 Takashi Iwai wrote:
> > > At Wed, 10 Jun 2015 14:33:42 +0200, Takashi Iwai wrote:
> > > > At Wed, 10 Jun 2015 14:45:51 +0300, Mihai Donțu wrote:
> > > > > On Wed, 10 Jun 2015 12:50:22 +0200 Takashi Iwai wrote:
> > > > > > At Wed, 10 Jun 2015 13:41:35 +0300, Mihai Donțu wrote:
> > > > > > > On Wed, 10 Jun 2015 12:22:53 +0200 Takashi Iwai wrote:
> > > > > > > > At Wed, 10 Jun 2015 13:17:55 +0300, Mihai Donțu wrote:
> > > > > > > > > On Wed, 20 May 2015 07:01:12 +0200 Takashi Iwai wrote:
> > > > > > > > > > From: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > Subject: [PATCH] ALSA: hda - Disable widget power-saving for ALC292 & co
> > > > > > > > > >
> > > > > > > > > > We've got reports that ALC3226 (a Dell variant of ALC292) gives click
> > > > > > > > > > noises at transition from D3 to D0 when the widget power-saving is
> > > > > > > > > > enabled. Further debugging session showed that avoiding it isn't
> > > > > > > > > > trivial, unfortunately, since paths are basically activated
> > > > > > > > > > dynamically while the pins have been already enabled.
> > > > > > > > > >
> > > > > > > > > > This patch disables the widget power-saving for such codecs.
> > > > > > > > > >
> > > > > > > > > > Reported-by: Jonathan McDowell <noodles@earth.li>
> > > > > > > > > > Signed-off-by: Takashi Iwai <tiwai@suse.de>
> > > > > > > > > > ---
> > > > > > > > > > sound/pci/hda/patch_realtek.c | 3 ++-
> > > > > > > > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > > > > > > > > index 2e246fe495f6..31f8f13be907 100644
> > > > > > > > > > --- a/sound/pci/hda/patch_realtek.c
> > > > > > > > > > +++ b/sound/pci/hda/patch_realtek.c
> > > > > > > > > > @@ -5623,7 +5623,8 @@ static int patch_alc269(struct hda_codec *codec)
> > > > > > > > > >
> > > > > > > > > > spec = codec->spec;
> > > > > > > > > > spec->gen.shared_mic_vref_pin = 0x18;
> > > > > > > > > > - codec->power_save_node = 1;
> > > > > > > > > > + if (codec->core.vendor_id != 0x10ec0292)
> > > > > > > > > > + codec->power_save_node = 1;
> > > > > > > > > >
> > > > > > > > > > snd_hda_pick_fixup(codec, alc269_fixup_models,
> > > > > > > > > > alc269_fixup_tbl, alc269_fixups);
> > > > > > > > >
> > > > > > > > > I'm on 4.1-rc7 which appears to contain this patch, however, I still
> > > > > > > > > get the audio artifacts (crackles) when I boot my laptop (Latitude
> > > > > > > > > E7440):
> > > > > > > > >
> > > > > > > > > [ 1.058839] snd_hda_codec_realtek hdaudioC1D0: autoconfig for ALC3226: line_outs=1 (0x16/0x0/0x0/0x0/0x0) type:line
> > > > > > > > > [ 1.058843] snd_hda_codec_realtek hdaudioC1D0: speaker_outs=1 (0x14/0x0/0x0/0x0/0x0)
> > > > > > > > > [ 1.058846] snd_hda_codec_realtek hdaudioC1D0: hp_outs=1 (0x15/0x0/0x0/0x0/0x0)
> > > > > > > > > [ 1.058849] snd_hda_codec_realtek hdaudioC1D0: mono: mono_out=0x0
> > > > > > > > > [ 1.058851] snd_hda_codec_realtek hdaudioC1D0: inputs:
> > > > > > > > > [ 1.058855] snd_hda_codec_realtek hdaudioC1D0: Dock Mic=0x19
> > > > > > > > > [ 1.058859] snd_hda_codec_realtek hdaudioC1D0: Headset Mic=0x1a
> > > > > > > > > [ 1.058862] snd_hda_codec_realtek hdaudioC1D0: Internal Mic=0x12
> > > > > > > > >
> > > > > > > > > 4.0.4 was fine.
> > > > > > > >
> > > > > > > > Does it happen only once at boot (i.e. at power up), or happens always
> > > > > > > > at runtime PM? If it's a once-off boot thing, the patch shouldn't
> > > > > > > > have much effect. Something else, very subtle thing, e.g. the order
> > > > > > > > of verb execution, might cause this kind of problem.
> > > > > > >
> > > > > > > Only at power up. I've also suspend-resumed twice and can confirm it's
> > > > > > > OK.
> > > > > > >
> > > > > > > There's a _very_ brief click at suspend (when the power is cut), but it
> > > > > > > looks like a plain circuitry thing. I probably didn't notice it before
> > > > > > > because I wasn't looking for it.
> > > > > >
> > > > > > Thanks. Do you get the same click noise when reloading snd-hda-intel
> > > > > > driver? Also, does it happen when booting in runlevel 3?
> > > > > >
> > > > > > Last but not least, a patch like below has any effect?
> > > > > >
> > > > > >
> > > > > > Takashi
> > > > > >
> > > > > > ---
> > > > > > diff --git a/sound/pci/hda/hda_codec.c b/sound/pci/hda/hda_codec.c
> > > > > > --- a/sound/pci/hda/hda_codec.c
> > > > > > +++ b/sound/pci/hda/hda_codec.c
> > > > > > @@ -3077,6 +3077,8 @@ static unsigned int hda_set_power_state(struct hda_codec *codec,
> > > > > > break;
> > > > > > }
> > > > > >
> > > > > > + if (power_state == AC_PWRST_D0)
> > > > > > + msleep(100);
> > > > > > return state;
> > > > > > }
> > > > > >
> > > > >
> > > > > Reloading snd-hda-intel does not trigger the noise, but it helps. I've
> > > > > noticed that the clicks appear when loading/reloading pulseaudio.
> > > > >
> > > > > $ pulseaudio -k
> > > > >
> > > > > will spawn a new child in background (probably asked by kmix) and
> > > > > immediately I hear the noise. Reloading the driver makes the problem go
> > > > > away.
> > > >
> > > > Hm. It's a bit inconsistent, but still this can be only at the full
> > > > power up sequence.
> > > >
> > > > > telinit 3 does nothing for me (Gentoo seems to have things wired
> > > > > differently). Manually reloading alsasound (/etc/init.d/alsasound) did
> > > > > not trigger the problem either.
> > > > >
> > > > > However! Your patch seems to work. Cold boot, pulseaudio restart and
> > > > > nothing. Not a peep. :-)
> > > >
> > > > OK, could you try to reduce the sleep value from 100 to 10?
> > > > Does it still work?
> > >
> > > ... and check whether the patch below works instead. This is a better
> > > place if it really fixes. The former patch is in the common path
> > > every driver uses while this is codec-specific.
> > >
> > > ---
> > > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > > index 0320cb523d9e..957412548ba1 100644
> > > --- a/sound/pci/hda/patch_realtek.c
> > > +++ b/sound/pci/hda/patch_realtek.c
> > > @@ -5637,7 +5637,9 @@ static int patch_alc269(struct hda_codec *codec)
> > >
> > > spec = codec->spec;
> > > spec->gen.shared_mic_vref_pin = 0x18;
> > > - if (codec->core.vendor_id != 0x10ec0292)
> > > + if (codec->core.vendor_id == 0x10ec0292)
> > > + msleep(100); /* for avoiding click noise at power up */
> > > + else
> > > codec->power_save_node = 1;
> > >
> > > snd_hda_pick_fixup(codec, alc269_fixup_models,
> >
> > The initial patch but with msleep(10), works OK. This new one, however,
> > does not (with 100ms or 10ms).
>
> Hmm, could you make sure that the sleep is actually called, e.g. by
> adding a debug print or such? I blindly assumed that your codec is
> as same as Joanathan's (vendor id 0x10ec0292). You can check
> /proc/asound/card*/codec#* files, too.
I added some printk-s:
[Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: vendor_id: 0x10ec0292
[Wed Jun 10 19:36:23 2015] snd_hda_codec_realtek: sleeping for 100ms
The code above runs some good seconds before pulseaudio starts and
triggers the clicks. Even before rootfs is re-mounted rw.
--
Mihai Donțu
next prev parent reply other threads:[~2015-06-10 16:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-28 11:21 Audio crackles with 4.1-rc1 Jonathan McDowell
2015-04-28 12:00 ` Takashi Iwai
2015-04-28 12:35 ` Jonathan McDowell
2015-04-28 13:05 ` Takashi Iwai
2015-04-28 14:43 ` Takashi Iwai
2015-04-29 11:28 ` Jonathan McDowell
2015-04-29 11:54 ` Takashi Iwai
2015-04-30 15:01 ` Jonathan McDowell
2015-04-30 17:06 ` Takashi Iwai
2015-05-02 15:05 ` Jonathan McDowell
2015-05-19 6:15 ` Takashi Iwai
2015-05-19 16:19 ` Jonathan McDowell
2015-05-19 17:09 ` Takashi Iwai
2015-05-19 21:53 ` Jonathan McDowell
2015-05-20 5:01 ` Takashi Iwai
2015-05-20 20:02 ` Jonathan McDowell
2015-06-10 10:17 ` Mihai Donțu
2015-06-10 10:22 ` Takashi Iwai
2015-06-10 10:41 ` Mihai Donțu
2015-06-10 10:50 ` Takashi Iwai
2015-06-10 11:45 ` Mihai Donțu
2015-06-10 12:33 ` Takashi Iwai
2015-06-10 12:50 ` Takashi Iwai
2015-06-10 16:22 ` Mihai Donțu
2015-06-10 16:27 ` Takashi Iwai
2015-06-10 16:43 ` Mihai Donțu [this message]
2015-06-10 18:23 ` Takashi Iwai
2015-06-10 22:12 ` Mihai Donțu
2015-06-11 5:01 ` Takashi Iwai
2015-06-11 22:23 ` Mihai Donțu
2015-06-12 7:00 ` Takashi Iwai
2015-06-12 9:45 ` Mihai Donțu
2015-06-12 10:09 ` Takashi Iwai
2015-06-12 14:13 ` Takashi Iwai
2015-06-12 17:28 ` Mihai Donțu
2015-06-14 12:24 ` Jonathan McDowell
2015-06-15 12:04 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150610194303.3b82609d@mdontu-l.dsd.bitdefender.biz \
--to=mihai.dontu@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=linux-kernel@vger.kernel.org \
--cc=noodles@earth.li \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).