[alsa-devel] Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]
tiwai at suse.de
Fri May 11 15:55:43 CEST 2012
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 Iwai<tiwai at 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.
More information about the Alsa-devel