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

[Colomban Wendling]

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).

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.