[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
tiwai at suse.de
Wed Dec 14 18:32:24 CET 2011
At Wed, 14 Dec 2011 17:12:20 +0100,
Colomban Wendling wrote:
> Le 14/12/2011 15:48, Takashi Iwai a écrit :
> > 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.
> Sorry, I fwd'ed the message and forgot to update the CClist, sorry.
> >> 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
> > something.
> > 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
> > ??
> Aha, you refined it!
> Even if I think it won't be really relevant any more (see below), what I
> did before was basically `mplayer -ao alsa <file>` and listening. The
> first time I heard the problem I think I tried various players and
> output methods that all did suffer of the problem, so I don't really
> remember which ones. Also, I (shame on me) ever only tested the rear
> line out.
> So then, the news:
> First, playing with aplay -Dhw (after fighting to get pulseaudio
> down...) doesn't change anything.
> But then, while all the rear outputs (L, SS, CS, RS) suffer of the
> choppiness, the front one never does!
> Moreover, if I plug something in the front output, sometimes  the
> rear ones doesn't mute and stop "choppying" (I have correct sound in
> all outputs, rear and front).
Hm, then this can be really related with the jack-detection.
If so, the choppy sound is not because of the DMA position reporting
but because of the continuous triggering of jack-detect events.
If you built your kernel with the tracepoint support, you'll have
/sys/kernel/debug/tracing/events/hda/enable file. As root, run
# echo 1 > /sys/kernel/debug/tracing/events/hda/enable
then check /sys/kernel/debu/tracing/trace file after some seconds.
Do you get any events there? Also, what about plugging/unplugging the
headpohne jack? After gathering the tracing info, disable again via:
# echo 0 > /sys/kernel/debug/tracing/events/hda/enable
In anyway, if the jack-detection is really the problem, you can
disable the auto-mute feature by changing "Auto-Mute Mode" enum to
"Disabled". Run "alsamixer -c0" and change the value.
> Note that alsa-info outputs are exactly the same (minus run date and
> /dev/snd/pcmC0D0p timestamp) in working and non-working situations --
> e.g. nothing changes if I unplug the front HP and get choppy sound in
> the rear baffles.
>  looks like if I plug it slowly sometimes the plug isn't detected,
> not really sure when though, but sometimes rear keeps outputing.
More information about the Alsa-devel