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.
Takashi
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.
Regards, Colomban
[1] looks like if I plug it slowly sometimes the plug isn't detected, not really sure when though, but sometimes rear keeps outputing.