[alsa-devel] Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
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
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
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.
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.
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
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
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
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
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).
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
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
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.ht... http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047152.ht... http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047210.ht...
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:
- fix the jack detection (if it isn't a bug in the card but in the
driver somewhere)
- 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.ht... http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047152.ht... http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047210.ht...
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?
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:
- 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.
- 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
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! ;-)
participants (4)
-
Colomban Wendling -
David Henningsson -
Raymond Yau -
Takashi Iwai