2012-05-11 00:43, Takashi Iwai skrev:
At Fri, 11 May 2012 04:01:23 -0300, Dâniel Fraga wrote:
On Fri, 11 May 2012 07:39:46 +0200 Takashi Iwaitiwai@suse.de wrote:
Ah, it's the case... Yes, some mobos are badly designed not to handle the jack detection properly.
Did the auto-mute actually work on your machine? If not, we can blacklist the device. Please give alsa-info.sh output.
Hi Takashi! Disabling the auto-mute solved the issue. Regarding your question: in fact, I don't know why auto-mute was enabled, because I never use a headphone.
It's a driver feature that is enabled as default, no matter whether you use or not :)
So I can't test it.
Does it mean that you have no headphone, or does the machine have no headphone jack?
But you can be sure that with this motherboard (Asus P8Z68-V Pro/gen3) there's this "pop and click" problem when Auto-mute is enabled.
That's why I'm asking to test. Usually when such a noise occurs due to the auto-mute feature, it's because the bogus unsolicited events are fired up too much although no jack is plugged actually. Thus usually the auto-mute feature itself doesn't work in such a case (either no hardware implementation or the hardware has its own switching mechanism.)
In the long term, I think we should filter out short jack sense events. That is, when we get an unsol jack event, check the current status and set a timer for 200 ms. 200 ms later, in the timer callback, we would only accept the jack sense event as valid (and do automute/autoswitch/kcontrol update) if - The current status is the same as 200 ms earlier - If there has not been more unsol events in the mean time
Question is whether to do this by default, or only for devices we know are flickering.
I haven't seen this a lot, but the few I have seen have had times with the wrong state below 100 ms, so I think 200 ms could be a good value to start with.