Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

Here's my initial mail, but with gzipped outputs.

Regards,
Colomban

-------- Message original --------
Sujet: Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives
choppy sound (again)
Date : Thu, 10 Nov 2011 02:11:17 +0100
De : Colomban Wendling <lists.ban@herbesfolles.org>
Pour : Takashi Iwai <tiwai@suse.de>
Copie à : alsa-devel@alsa-project.org

Hi again, and sorry for the delay.

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.


Regards,
Colomban




[-- Attachment #2: alsa-info_3.1.0-fixed3.1ban+.txt.gz --]
[-- Type: application/x-gzip, Size: 6111 bytes --]

[-- Attachment #3: alsa-info_3.1.0-vanilla3.1ban.txt.gz --]
[-- Type: application/x-gzip, Size: 6102 bytes --]

[-- Attachment #4: alsa-info_3.2.0-rc1-vanilla-master-ban.txt.gz --]
[-- Type: application/x-gzip, Size: 6229 bytes --]

[-- Attachment #5: Type: text/plain, Size: 0 bytes --]

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Takashi Iwai]

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.

> 
> Regards,
> Colomban
> 
> -------- Message original --------
> Sujet: Re: [alsa-devel] Realtek ALC889: HDA Intel and kernel 3.1 gives
> choppy sound (again)
> Date : Thu, 10 Nov 2011 02:11:17 +0100
> De : Colomban Wendling <lists.ban@herbesfolles.org>
> Pour : Takashi Iwai <tiwai@suse.de>
> Copie à : alsa-devel@alsa-project.org
> 
> Hi again, and sorry for the delay.
> 
> 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
??


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Takashi Iwai]

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.

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

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.

> /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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[David Henningsson]

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.

// David

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[David Henningsson]

On 12/19/2011 04:30 PM, Takashi Iwai wrote:
> At Mon, 19 Dec 2011 16:06:53 +0100,
> David Henningsson wrote:
>> 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.

I guess that would also disable the possibility for userspace to read 
state changes, both with the old and new jack detection interface?

Also, in a long term scenario, one could consider PulseAudio disabling 
auto-mute and handling that logic itself, potentially with advanced 
routing rules (a use case could be, if a phone call comes in, play the 
ring tone in the speaker but the actual talking would be through the 
headset).

-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic

Re: 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@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

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.

Just my 2¢.

Cheers,
Colomban


> 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
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Raymond Yau]

2012/2/4, Colomban Wendling <lists.ban@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

Hi again,

Le 03/02/2012 20:11, Colomban Wendling a écrit :
> Le 19/12/2011 16:30, Takashi Iwai a écrit :
>> At Mon, 19 Dec 2011 16:06:53 +0100,
>> David Henningsson wrote:
>>>
>>> [...]
>>>
>>> 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.

This bug is still present as of current master (3.11.0+) -- jack
detection is still broken with my Realtek ALC889 on a MSI H55M-E33.

Moreover, since kctls were introduced, this jack detection issue breaks
userland apps that listen to them.  E.g. PulseAudio now switch back and
forth between front and back panel, for which it maintains 2 separate
set of settings which actually results in more or less the same issue
than with AutoMute.

I see 2 possible solutions:

1) fix the jack detection (if it isn't a bug in the card but in the
driver somewhere)

2) if it's not possible to fix the driver, add a way to completely
disable jack events (e.g. a module param or something).

Currently I had to comment-out the snd_kctl_jack_report() call in
snd_hda_jack_report_sync() so I could actually use the driver.


BTW if it helps, snd_hda_jack_unsol_event() only receives events when
actually plugging/unplugging a jack or during playback, but never when
the card is idle.


I would be more than happy to do anything I can to help fixing this.


Best regards,
Colomban


PS: original thread(s):
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-November/045707.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047152.html
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047210.html
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[David Henningsson]

On 09/14/2013 04:19 PM, Colomban Wendling wrote:
> Hi again,
> 
> Le 03/02/2012 20:11, Colomban Wendling a écrit :
>> Le 19/12/2011 16:30, Takashi Iwai a écrit :
>>> At Mon, 19 Dec 2011 16:06:53 +0100,
>>> David Henningsson wrote:
>>>>
>>>> [...]
>>>>
>>>> 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.
> 
> This bug is still present as of current master (3.11.0+) -- jack
> detection is still broken with my Realtek ALC889 on a MSI H55M-E33.
> 
> Moreover, since kctls were introduced, this jack detection issue breaks
> userland apps that listen to them.  E.g. PulseAudio now switch back and
> forth between front and back panel, for which it maintains 2 separate
> set of settings which actually results in more or less the same issue
> than with AutoMute.
> 
> I see 2 possible solutions:
> 
> 1) fix the jack detection (if it isn't a bug in the card but in the
> driver somewhere)
> 
> 2) if it's not possible to fix the driver, add a way to completely
> disable jack events (e.g. a module param or something).
> 
> Currently I had to comment-out the snd_kctl_jack_report() call in
> snd_hda_jack_report_sync() so I could actually use the driver.
> 
> 
> BTW if it helps, snd_hda_jack_unsol_event() only receives events when
> actually plugging/unplugging a jack or during playback, but never when
> the card is idle.
> 
> 
> I would be more than happy to do anything I can to help fixing this.
> 
> 
> Best regards,
> Colomban
> 
> 
> PS: original thread(s):
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-November/045707.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047152.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047210.html
> 

Well, in the last year or two the following additions have been made to
the kernel:

 1) jackpoll_interval as a module parameter - turns off unsol events and
instead polls the jack connection at the interval you specify

 2) Kernel automute can (for almost all cards, I believe) be disabled by
setting a mixer control named "Automute mode"

...and you can disable jack detection in PulseAudio by commenting out
all sections with the jack you want to disable, the files are in
/usr/share/pulseaudio/alsa-mixer/paths/*

Btw, just a wild theory, because I'm really not a subject matter expert:
since this is a home-built computer (I assume), I wonder if this could
be a very hardware near problem - i e, is the cable to the front panel
chassi very close to something that gives out a lot of EMI disturbance
or something like that?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[Colomban Wendling]

TL;DR: OMG I'm an idiot, just forget about those mails.

Le 16/09/2013 23:26, David Henningsson a écrit :
> On 09/14/2013 04:19 PM, Colomban Wendling wrote:
>> [...]
>>
>> This bug is still present as of current master (3.11.0+) -- jack
>> detection is still broken with my Realtek ALC889 on a MSI H55M-E33.
>>
>> [...]
> 
> Well, in the last year or two the following additions have been made to
> the kernel:
> 
>  1) jackpoll_interval as a module parameter - turns off unsol events and
> instead polls the jack connection at the interval you specify

I tried it and it didn't help, because the whole jack detection thing
failed, so it only lead to fewer but longer cuts.

>  2) Kernel automute can (for almost all cards, I believe) be disabled by
> setting a mixer control named "Automute mode"

That's what I initially did, and it fixed my problem 'til PA started to
see those events.

> ...and you can disable jack detection in PulseAudio by commenting out
> all sections with the jack you want to disable, the files are in
> /usr/share/pulseaudio/alsa-mixer/paths/*

Good to know, thanks.

> Btw, just a wild theory, because I'm really not a subject matter expert:
> since this is a home-built computer (I assume), I wonder if this could
> be a very hardware near problem - i e, is the cable to the front panel
> chassi very close to something that gives out a lot of EMI disturbance
> or something like that?

You're a genius and I'm a total idiot.  I never though it could be it,
but apparently I overlooked the AC'97 front panel connection chart for
HDA pins.  Since I didn't check how I plugged it previously I won't be
sure, but I'd think I did plug FP_RET_R to the SENSE_SEND pin -- which
without a surprise leads to weird stuff.

I'm terribly, terribly sorry for all the noise, and for wasting your
time.  Sorry.

Regards,
Colomban
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)

[David Henningsson]

On 09/18/2013 07:00 PM, Colomban Wendling wrote:
> TL;DR: OMG I'm an idiot, just forget about those mails.
> 
> Le 16/09/2013 23:26, David Henningsson a écrit :
>> Btw, just a wild theory, because I'm really not a subject matter expert:
>> since this is a home-built computer (I assume), I wonder if this could
>> be a very hardware near problem - i e, is the cable to the front panel
>> chassi very close to something that gives out a lot of EMI disturbance
>> or something like that?
> 
> You're a genius and I'm a total idiot.  I never though it could be it,
> but apparently I overlooked the AC'97 front panel connection chart for
> HDA pins.  Since I didn't check how I plugged it previously I won't be
> sure, but I'd think I did plug FP_RET_R to the SENSE_SEND pin -- which
> without a surprise leads to weird stuff.
> 
> I'm terribly, terribly sorry for all the noise, and for wasting your
> time.  Sorry.

No worries, glad it worked out. Now at least we know where to point the
next person having these problems! ;-)

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel