[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

Le 14/12/2011 19:23, Colomban Wendling a écrit :
> Le 14/12/2011 18:32, Takashi Iwai a écrit :
>> 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
> 
> I'll try to build a kernel with it and report you the result.

Sorry for the delay, but is this test still useful now we know what was
wrong?  I just couldn't find what the proper kernel build option is to
get this, and think it's maybe useless now?

Cheers,
Colomban

>> /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.
> 
> Ha-ha!  You're right, disabling/enabling auto-mute fixes/triggers the
> problem instantaneously.
> 
> Regards,
> Colomban
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel