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

[David Henningsson]

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.

You instead suggested some blacklisting, would that break headphone 
support completely, at least for the jack you would blacklist?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic