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

[Raymond Yau]

2012/2/4, Colomban Wendling <lists.ban at herbesfolles.org>:
> Le 19/12/2011 16:30, Takashi Iwai a écrit :
>> 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.
>
> It's easy to fix, but I, as a simple user, think it's really hard to
> find out -- actually I wouldn't have found this out if you weren't there
> telling me :)
>
> So maybe it'd be good to have an automatic disable if this isn't a bug
> in an ALSA code somewhere -- just remembering I never suffered of the
> problem before 3.0.
>

BTW,  The ALC889 provides ten DAC channels that simultaneously support
7.1 sound playback, plus 2 channels of independent stereo sound output
(multiple streaming) through the front panel stereo outputs.

To enable multistreaming , you will need to disable automute