[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
tiwai at suse.de
Wed Dec 14 15:48:02 CET 2011
At Wed, 14 Dec 2011 15:32:08 +0100,
Colomban Wendling wrote:
> Here's my initial mail, but with gzipped outputs.
Please don't drop Cc list.
> -------- Message original --------
> Sujet: Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives
> choppy sound (again)
> Date : Thu, 10 Nov 2011 02:11:17 +0100
> De : Colomban Wendling <lists.ban at herbesfolles.org>
> Pour : Takashi Iwai <tiwai at suse.de>
> Copie à : alsa-devel at alsa-project.org
> Hi again, and sorry for the delay.
> Le 08/11/2011 07:32, Takashi Iwai a écrit :
> > At Mon, 07 Nov 2011 23:45:40 +0100,
> > Colomban Wendling wrote:
> >> Hi,
> >> Back to 3.0, the sound on my soundcard  started to be choppy, I
> >> reported it  and it got fixed (thanks to Takashi Iwai!).
> >> However, the story repeated with 3.1 (and probably 3.0.8 or before ):
> >> I've got similar choppy sound again.
> >> I bisected the few commits that happened on
> >> sound/pci/hda/patch_realtek.c, and finally found the villain:
> >> "8974bd51 ALSA: hda/realtek - Fix auto-mute with HP+LO configuration"
> >> Reverting it from v3.1 fixes the problem.
> > Does it? Very weird. This patch has nothing to do with the HD-audio
> > controller side but purely a codec change.
> Yep, I just check once again and it really fixes the problem here.
> >> master (94956ee) also suffers of the problem, but I couldn't test
> >> without that commit because reverting it fails, too much changes happened.
> > Did you try to pass position_fix=1 (or 2) option?
> > Also, passing enable_msi=0 (or 1) may change anything?
> I just tried with the 3 kernels:
> * vanilla v3.1
> * vanilla 3.2-rc1 (master at 1ea6b8f)
> * v3.1 with 8974bd51 reverted
> and none of the option changed anything: both vanilla always failed, the
> third always succeeded. Though, I haven't combined the options, just
> tried each at once.
> > In anyway, please give alsa-info.sh output again with the fresh
> > kernel. Run it with --no-upload option and attach the output.
> Here it is, for the 3 kernels cited above.
I see really no difference between vanilla3.1 and fixed.
The only difference is the NID 0x24, which is irrelevant with the
output. It concludes that the commit you found has nothing to do with
the bug directly. It's just a coincidence that it triggers
Which output are you testing? Does the problem happen on both HP and
all line-outs? Also, how are you testing? How about the direct aplay
with -Dhw like
% aplay -Dhw foo.wav
More information about the Alsa-devel