At Mon, 19 Dec 2011 16:06:53 +0100, David Henningsson wrote:
2011-12-14 18:32, Takashi Iwai skrev:
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 [1] started to be choppy, I > reported it [2] and it got fixed (thanks to Takashi Iwai!). > > However, the story repeated with 3.1 (and probably 3.0.8 or before [3]): > 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 [1] 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.
Hmm, thanks for figuring this one out. Actually this is the third time I hear of jack detection flipping back and forth. I'm wondering if we need (and whether other OSes have?) a filter / flood protection on this stuff, and if so, how it works? I mean, nobody would notice half a second of delay on that switch anyway.
I don't think there is a perfect filtering for such a problem. Theoretically we can see how often it's flipped, and disables the jack-detection accordingly. But not sure how useful it is in practice, since it's a rare case, and the manual adjustment is easy.
BTW, maybe we should turn off the jack-detection while the auto-mute is disabled? Otherwise unsol events might still come up although they are just ignored.
Takashi