* Realtek ACL892: audio gap ~ each 10 seconds? @ 2012-05-03 17:11 Dâniel Fraga 2012-05-06 5:51 ` Alexander E. Patrakov 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-03 17:11 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? 2012-05-03 17:11 Realtek ACL892: audio gap ~ each 10 seconds? Dâniel Fraga @ 2012-05-06 5:51 ` Alexander E. Patrakov 2012-05-08 15:11 ` Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Alexander E. Patrakov @ 2012-05-06 5:51 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? 2012-05-06 5:51 ` Alexander E. Patrakov @ 2012-05-08 15:11 ` Dâniel Fraga 2012-05-11 1:39 ` Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-08 15:11 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-08 15:11 ` Dâniel Fraga @ 2012-05-11 1:39 ` Dâniel Fraga 2012-05-11 5:39 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-11 1:39 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 1:39 ` Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] Dâniel Fraga @ 2012-05-11 5:39 ` Takashi Iwai 2012-05-11 7:01 ` Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 5:39 UTC (permalink / raw) To: Dâniel Fraga; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 5:39 ` Takashi Iwai @ 2012-05-11 7:01 ` Dâniel Fraga 2012-05-11 7:43 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-11 7:01 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 7:01 ` Dâniel Fraga @ 2012-05-11 7:43 ` Takashi Iwai 2012-05-11 13:45 ` David Henningsson [not found] ` <4fad162b.07b3340a.14cb.5a06@mx.google.com> 0 siblings, 2 replies; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 7:43 UTC (permalink / raw) To: Dâniel Fraga; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 7:43 ` Takashi Iwai @ 2012-05-11 13:45 ` David Henningsson 2012-05-11 13:55 ` Takashi Iwai [not found] ` <4fad162b.07b3340a.14cb.5a06@mx.google.com> 1 sibling, 1 reply; 18+ messages in thread From: David Henningsson @ 2012-05-11 13:45 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Dâniel Fraga 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 13:45 ` David Henningsson @ 2012-05-11 13:55 ` Takashi Iwai 2012-05-11 14:25 ` David Henningsson 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 13:55 UTC (permalink / raw) To: David Henningsson; +Cc: alsa-devel, Dâniel Fraga 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 13:55 ` Takashi Iwai @ 2012-05-11 14:25 ` David Henningsson 2012-05-11 14:29 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: David Henningsson @ 2012-05-11 14:25 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Dâniel Fraga 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 14:25 ` David Henningsson @ 2012-05-11 14:29 ` Takashi Iwai 2012-05-11 15:20 ` David Henningsson 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 14:29 UTC (permalink / raw) To: David Henningsson; +Cc: alsa-devel, Dâniel Fraga 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 14:29 ` Takashi Iwai @ 2012-05-11 15:20 ` David Henningsson 0 siblings, 0 replies; 18+ messages in thread From: David Henningsson @ 2012-05-11 15:20 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, Dâniel Fraga 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
[parent not found: <4fad162b.07b3340a.14cb.5a06@mx.google.com>]
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] [not found] ` <4fad162b.07b3340a.14cb.5a06@mx.google.com> @ 2012-05-11 13:52 ` Takashi Iwai 2012-05-11 14:53 ` Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 13:52 UTC (permalink / raw) To: Dâniel Fraga; +Cc: alsa-devel [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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 13:52 ` Takashi Iwai @ 2012-05-11 14:53 ` Dâniel Fraga 2012-05-11 15:05 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-11 14:53 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 14:53 ` Dâniel Fraga @ 2012-05-11 15:05 ` Takashi Iwai 2012-05-11 15:51 ` Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 15:05 UTC (permalink / raw) To: Dâniel Fraga; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 15:05 ` Takashi Iwai @ 2012-05-11 15:51 ` Dâniel Fraga 2012-05-11 15:54 ` Takashi Iwai 0 siblings, 1 reply; 18+ messages in thread From: Dâniel Fraga @ 2012-05-11 15:51 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 15:51 ` Dâniel Fraga @ 2012-05-11 15:54 ` Takashi Iwai 2012-05-11 16:11 ` Dâniel Fraga 0 siblings, 1 reply; 18+ messages in thread From: Takashi Iwai @ 2012-05-11 15:54 UTC (permalink / raw) To: Dâniel Fraga; +Cc: alsa-devel, David Henningsson 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] 2012-05-11 15:54 ` Takashi Iwai @ 2012-05-11 16:11 ` Dâniel Fraga 0 siblings, 0 replies; 18+ messages in thread From: Dâniel Fraga @ 2012-05-11 16:11 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel, David Henningsson 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2012-05-11 16:12 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-05-03 17:11 Realtek ACL892: audio gap ~ each 10 seconds? Dâniel Fraga 2012-05-06 5:51 ` Alexander E. Patrakov 2012-05-08 15:11 ` Dâniel Fraga 2012-05-11 1:39 ` Realtek ACL892: audio gap ~ each 10 seconds? [SOLVED] Dâniel Fraga 2012-05-11 5:39 ` Takashi Iwai 2012-05-11 7:01 ` Dâniel Fraga 2012-05-11 7:43 ` Takashi Iwai 2012-05-11 13:45 ` David Henningsson 2012-05-11 13:55 ` Takashi Iwai 2012-05-11 14:25 ` David Henningsson 2012-05-11 14:29 ` Takashi Iwai 2012-05-11 15:20 ` David Henningsson [not found] ` <4fad162b.07b3340a.14cb.5a06@mx.google.com> 2012-05-11 13:52 ` Takashi Iwai 2012-05-11 14:53 ` Dâniel Fraga 2012-05-11 15:05 ` Takashi Iwai 2012-05-11 15:51 ` Dâniel Fraga 2012-05-11 15:54 ` Takashi Iwai 2012-05-11 16:11 ` Dâniel Fraga
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.