[alsa-devel] Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

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.


thanks,

Takashi