Realtek ACL892: audio gap ~ each 10 seconds?

Realtek ACL892: audio gap ~ each 10 seconds?

[Dâniel Fraga]

	I changed my motherboard to Asus P8Z68V-Pro/gen3 and it uses
the Realtek ACL892.

	Everything works, except for the fact that the sound has a
"gap" each 10 seconds... it's annoying... it's just like a small pop or
click...

	What can I do to debug that? Is there a workaround I can try?

	Thanks.

-- 
Linux 3.3.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

Re: Realtek ACL892: audio gap ~ each 10 seconds?

[Alexander E. Patrakov]

Dâniel Fraga wrote:

> I changed my motherboard to Asus P8Z68V-Pro/gen3 and it uses the Realtek
> ACL892.
> 
> 	Everything works, except for the fact that the sound has a
> "gap" each 10 seconds... it's annoying... it's just like a small pop or
> click...
> 
> 	What can I do to debug that? Is there a workaround I can try?
> 
> 	Thanks.

Long shot: this may be caused by your video driver (possible duplicate: 
https://bugs.freedesktop.org/show_bug.cgi?id=29536 ). Please try adding 
the following parameter to your kernel command line:

drm_kms_helper.poll=0

If drm_kms_helper is built as a module, do this instead:

echo options drm_kms_helper poll=0 > /etc/modprobe.d/kms.conf

You need to reboot for the setting to take any effect.

-- 
Alexander E. Patrakov

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds?

[Dâniel Fraga]

On Sun, 6 May 2012 05:51:57 +0000 (UTC)
"Alexander E. Patrakov" <patrakov@gmail.com> wrote:

> Long shot: this may be caused by your video driver (possible duplicate: 
> https://bugs.freedesktop.org/show_bug.cgi?id=29536 ). Please try adding 
> the following parameter to your kernel command line:
> 
> drm_kms_helper.poll=0
> 
> If drm_kms_helper is built as a module, do this instead:
> 
> echo options drm_kms_helper poll=0 > /etc/modprobe.d/kms.conf
> 
> You need to reboot for the setting to take any effect.

	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.

-- 
Linux 3.3.0: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Dâniel Fraga]

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.

-- 
Linux 3.4.0-rc6: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR


_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

At Thu, 10 May 2012 22:39:18 -0300,
Dâniel Fraga wrote:
> 
> 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.

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.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Dâniel Fraga]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

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!

-- 
Linux 3.4.0-rc6: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

[-- Attachment #2: alsa-info.txt.bz2 --]
[-- Type: application/octet-stream, Size: 10257 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

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

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

Thanks.  Yes, the attachment is OK.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[David Henningsson]

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

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

Re: 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@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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@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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: 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@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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[David Henningsson]

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

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

_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

[Re-added Cc to alsa-devel to let others following]

At Fri, 11 May 2012 10:37:44 -0300,
Dâniel Fraga wrote:
> 
> On Fri, 11 May 2012 09:43:48 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > Does it mean that you have no headphone, or does the machine have no
> > headphone jack?
> 
> 	The machine has a headphone jack, but I never use a headphone.
> 
> > 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.)
> 	
> 	I understand. Ok... so you want me to plug the headphone and
> test if the auto-mute works right? Ok, I did that and yes, it works
> fine as expected (the audio from speakers is automatically muted when a
> headphone is inserted).

Hm, so it's strange that the auto-mute causes a problem.

Could you check which unsolicited events are triggered on your
machine?  When you build your kernel with the tracing support
(CONFIG_TRACEPOINTS=y), you can enable the tracing via

  % echo 1 > /sys/kernel/debug/tracing/events/hda/hda_unsol_event/enable

then after some time, gather the result by checking 
/sys/kernel/debug/tracing/trace file.  The output is like below.

  % cat /sys/kernel/debug/tracing/trace
  # tracer: nop
  #
  # entries-in-buffer/entries-written: 4/4   #P:4
  #
  #                              _-----=> irqs-off
  #                             / _----=> need-resched
  #                            | / _---=> hardirq/softirq
  #                            || / _--=> preempt-depth
  #                            ||| /     delay
  #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
  #              | |       |   ||||       |         |
            <idle>-0     [001] d.h3 10157.942108: hda_unsol_event: [0] res=10010020, res_ex=10
            <idle>-0     [001] d.h3 10158.848271: hda_unsol_event: [0] res=10010000, res_ex=10
  .....

Check whether the events come up frequently even without
plugging/unplugging any jacks.  Usually this shouldn't happen.  But in
the case of problematic hardware with the auto-mute, many bogus unsol
events are triggered.


thanks,

Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Dâniel Fraga]

On Fri, 11 May 2012 15:52:49 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> Could you check which unsolicited events are triggered on your
> machine?  When you build your kernel with the tracing support
> (CONFIG_TRACEPOINTS=y), you can enable the tracing via
> 
>   % echo 1 > /sys/kernel/debug/tracing/events/hda/hda_unsol_event/enable
>   .....
> 
> Check whether the events come up frequently even without
> plugging/unplugging any jacks.  Usually this shouldn't happen.  But in
> the case of problematic hardware with the auto-mute, many bogus unsol
> events are triggered.

	Takashi, I got the following:

# tracer: nop
#
# entries-in-buffer/entries-written: 12/12   #P:8
#
#                              _-----=> irqs-off
#                             / _----=> need-resched
#                            | / _---=> hardirq/softirq
#                            || / _--=> preempt-depth
#                            ||| /     delay
#           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |       |   ||||       |         |
          <idle>-0     [000] d.h3   449.885014: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   449.906339: hda_unsol_event: [0] res=4000041, res_ex=10
          <idle>-0     [000] d.h3   472.269431: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   472.290721: hda_unsol_event: [0] res=4000041, res_ex=10
          <idle>-0     [000] d.h3   478.262018: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   478.283319: hda_unsol_event: [0] res=4000041, res_ex=10
          <idle>-0     [000] d.h3   482.934742: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   482.956033: hda_unsol_event: [0] res=4000041, res_ex=10
          <idle>-0     [000] d.h3   584.308420: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   584.329693: hda_unsol_event: [0] res=4000041, res_ex=10
          <idle>-0     [000] d.h3   593.781622: hda_unsol_event: [0] res=40000c1, res_ex=10
          <idle>-0     [000] d.h3   593.802890: hda_unsol_event: [0] res=4000041, res_ex=10

	***

	But I couldn't notice it happening exactly during the click and
pop... When click and pop happens, nothing happens in this file... So I
don't know if it will be useful to you. 

	Anyway, I'm confortable with auto-mute off... If you need more
testing, just ask. I'll be glad to help.

	Thank you.

-- 
Linux 3.4.0-rc6: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

At Fri, 11 May 2012 11:53:09 -0300,
Dâniel Fraga wrote:
> 
> On Fri, 11 May 2012 15:52:49 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > Could you check which unsolicited events are triggered on your
> > machine?  When you build your kernel with the tracing support
> > (CONFIG_TRACEPOINTS=y), you can enable the tracing via
> > 
> >   % echo 1 > /sys/kernel/debug/tracing/events/hda/hda_unsol_event/enable
> >   .....
> > 
> > Check whether the events come up frequently even without
> > plugging/unplugging any jacks.  Usually this shouldn't happen.  But in
> > the case of problematic hardware with the auto-mute, many bogus unsol
> > events are triggered.
> 
> 	Takashi, I got the following:
> 
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 12/12   #P:8
> #
> #                              _-----=> irqs-off
> #                             / _----=> need-resched
> #                            | / _---=> hardirq/softirq
> #                            || / _--=> preempt-depth
> #                            ||| /     delay
> #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
> #              | |       |   ||||       |         |
>           <idle>-0     [000] d.h3   449.885014: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   449.906339: hda_unsol_event: [0] res=4000041, res_ex=10
>           <idle>-0     [000] d.h3   472.269431: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   472.290721: hda_unsol_event: [0] res=4000041, res_ex=10
>           <idle>-0     [000] d.h3   478.262018: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   478.283319: hda_unsol_event: [0] res=4000041, res_ex=10
>           <idle>-0     [000] d.h3   482.934742: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   482.956033: hda_unsol_event: [0] res=4000041, res_ex=10
>           <idle>-0     [000] d.h3   584.308420: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   584.329693: hda_unsol_event: [0] res=4000041, res_ex=10
>           <idle>-0     [000] d.h3   593.781622: hda_unsol_event: [0] res=40000c1, res_ex=10
>           <idle>-0     [000] d.h3   593.802890: hda_unsol_event: [0] res=4000041, res_ex=10
> 
> 	***
> 
> 	But I couldn't notice it happening exactly during the click and
> pop... When click and pop happens, nothing happens in this file... So I
> don't know if it will be useful to you. 

Did you get any unsol events while you don't plug anything?
The output about indicates that it's an unsol event from the headphone
pin (tag=1).


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Dâniel Fraga]

On Fri, 11 May 2012 17:05:15 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> Did you get any unsol events while you don't plug anything?
> The output about indicates that it's an unsol event from the headphone
> pin (tag=1).

	Yes! The output I sent was generated without plugging anything.

-- 
Linux 3.4.0-rc6: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Takashi Iwai]

At Fri, 11 May 2012 12:51:38 -0300,
Dâniel Fraga wrote:
> 
> On Fri, 11 May 2012 17:05:15 +0200
> Takashi Iwai <tiwai@suse.de> wrote:
> 
> > Did you get any unsol events while you don't plug anything?
> > The output about indicates that it's an unsol event from the headphone
> > pin (tag=1).
> 
> 	Yes! The output I sent was generated without plugging anything.

OK, so obviously it's a strange series of jack on/off event spikes
in ca. 30ms.  A workaround as David suggested would work, then.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED]

[Dâniel Fraga]

On Fri, 11 May 2012 17:54:39 +0200
Takashi Iwai <tiwai@suse.de> wrote:

> OK, so obviously it's a strange series of jack on/off event spikes
> in ca. 30ms.  A workaround as David suggested would work, then.

	Ok. How can I test this workaround? Will you or David provide a
patch? If you want, I can test a patch... thanks.

-- 
Linux 3.4.0-rc6: Saber-toothed Squirrel
http://www.youtube.com/DanielFragaBR