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

[Takashi Iwai]

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 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.
> >
> 
> 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