At Fri, 11 May 2012 07:25:12 -0700, David Henningsson wrote:
2012-05-11 06:55, Takashi Iwai skrev:
At Fri, 11 May 2012 06:45:30 -0700, David Henningsson wrote:
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.
Well, if many events are triggered at plugging/unplugging, we can filter them out. The events are already handled in the workqueue, and in the case of jack-detection, we can filter out the too frequent ones, and even requeue it a certain delay to be sure.
But like this case, if the problem happens even without touching the jack, it's a different issue.
I'm not talking about flickering at physical plug/unplug, even if my proposal would help in such cases also.
A small "click", as Dâniel is experiencing, would indicate that the hardware (incorrectly) reports as the jack being plugged in, then a few milliseconds later, it is reported as no longer being plugged in. This applies to both getting the unsol event and the actual GET_PIN_SENSE result, i e, get_pin_sense would return the wrong value for a few milliseconds. By filtering out these events, we remove the occasional clicks.
Hm, so you postpone the jack handling a bit and check whether any jack-off event comes up, and eventually filter out? This would work, but the question is the choice of the sensible delay time. One would notice the delay of 200ms with the jack plugging or not?
You instead suggested some blacklisting, would that break headphone support completely, at least for the jack you would blacklist?
Yes, I didn't suppose that the jack plug detection actually works.
Takashi