On Tue, 8 May 2012 12:11:06 -0300 Dâniel Fraga fragabr@gmail.com wrote:

Sorry Alexander, I replied (by e-mail) too soon... the problem remains even with "poll=0". So it might be another cause...

Any other hints? Thanks.

Well, I discover a workaround: I disabled the Auto-mute mixer feature... Now everything is perfect! There's something very wrong with auto-mute which generates thoses clicks and pops.

thanks.

On Fri, 11 May 2012 07:39:46 +0200 Takashi Iwai tiwai@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. So I can't test it. 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.

I attached the bziped alsa-info.sh output (I hope the mailing-list can accept attachments).

Thank you!

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.

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.

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

2012-05-11 07:29, Takashi Iwai skrev:

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?

Exactly, as well as the opposite (if the user experiences clicks when using headphones).

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?

I think physical plug/unplug is something that takes a few seconds to perform anyway (finding the jack with your hand and actually plugging it in), so 200 ms more or less would not be an annoyance, and probably not even noticable. But I could be wrong.

Or, we could have a small delay (30 ms?) for everybody and make it quirkable to something larger...I'm not sure what would be the best option.

...

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.

Ok. I was more thinking along the lines of EMI disturbances in the jack sensing cable, or something like that.