Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: David Henningsson <david.henningsson@canonical.com>
To: Colomban Wendling <lists.ban@herbesfolles.org>
Cc: Takashi Iwai <tiwai@suse.de>, alsa-devel@alsa-project.org
Subject: Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
Date: Mon, 16 Sep 2013 23:26:04 +0200	[thread overview]
Message-ID: <5237776C.10000@canonical.com> (raw)
In-Reply-To: <52347075.3000304@herbesfolles.org>

On 09/14/2013 04:19 PM, Colomban Wendling wrote:
> Hi again,
> 
> Le 03/02/2012 20:11, Colomban Wendling a écrit :
>> Le 19/12/2011 16:30, Takashi Iwai a écrit :
>>> At Mon, 19 Dec 2011 16:06:53 +0100,
>>> David Henningsson wrote:
>>>>
>>>> [...]
>>>>
>>>> Hmm, thanks for figuring this one out. Actually this is the third time I 
>>>> hear of jack detection flipping back and forth. I'm wondering if we need 
>>>> (and whether other OSes have?) a filter / flood protection on this 
>>>> stuff, and if so, how it works? I mean, nobody would notice half a 
>>>> second of delay on that switch anyway.
>>>
>>> I don't think there is a perfect filtering for such a problem.
>>> Theoretically we can see how often it's flipped, and disables the
>>> jack-detection accordingly.  But not sure how useful it is in
>>> practice, since it's a rare case, and the manual adjustment is easy.
>>
>> It's easy to fix, but I, as a simple user, think it's really hard to
>> find out -- actually I wouldn't have found this out if you weren't there
>> telling me :)
>>
>> So maybe it'd be good to have an automatic disable if this isn't a bug
>> in an ALSA code somewhere -- just remembering I never suffered of the
>> problem before 3.0.
> 
> This bug is still present as of current master (3.11.0+) -- jack
> detection is still broken with my Realtek ALC889 on a MSI H55M-E33.
> 
> Moreover, since kctls were introduced, this jack detection issue breaks
> userland apps that listen to them.  E.g. PulseAudio now switch back and
> forth between front and back panel, for which it maintains 2 separate
> set of settings which actually results in more or less the same issue
> than with AutoMute.
> 
> I see 2 possible solutions:
> 
> 1) fix the jack detection (if it isn't a bug in the card but in the
> driver somewhere)
> 
> 2) if it's not possible to fix the driver, add a way to completely
> disable jack events (e.g. a module param or something).
> 
> Currently I had to comment-out the snd_kctl_jack_report() call in
> snd_hda_jack_report_sync() so I could actually use the driver.
> 
> 
> BTW if it helps, snd_hda_jack_unsol_event() only receives events when
> actually plugging/unplugging a jack or during playback, but never when
> the card is idle.
> 
> 
> I would be more than happy to do anything I can to help fixing this.
> 
> 
> Best regards,
> Colomban
> 
> 
> PS: original thread(s):
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-November/045707.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047152.html
> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-December/047210.html
> 

Well, in the last year or two the following additions have been made to
the kernel:

 1) jackpoll_interval as a module parameter - turns off unsol events and
instead polls the jack connection at the interval you specify

 2) Kernel automute can (for almost all cards, I believe) be disabled by
setting a mixer control named "Automute mode"

...and you can disable jack detection in PulseAudio by commenting out
all sections with the jack you want to disable, the files are in
/usr/share/pulseaudio/alsa-mixer/paths/*

Btw, just a wild theory, because I'm really not a subject matter expert:
since this is a home-built computer (I assume), I wonder if this could
be a very hardware near problem - i e, is the cable to the front panel
chassi very close to something that gives out a lot of EMI disturbance
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

  reply	other threads:[~2013-09-16 21:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-14 14:32 Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again) Colomban Wendling
2011-12-14 14:48 ` Takashi Iwai
2011-12-14 16:12   ` Colomban Wendling
2011-12-14 17:32     ` Takashi Iwai
2011-12-14 18:23       ` Colomban Wendling
2012-02-03 19:07         ` Colomban Wendling
2011-12-19 15:06       ` David Henningsson
2011-12-19 15:30         ` Takashi Iwai
2011-12-19 23:03           ` David Henningsson
2012-02-03 19:11           ` Colomban Wendling
2012-02-04  3:26             ` Raymond Yau
2013-09-14 14:19             ` Colomban Wendling
2013-09-16 21:26               ` David Henningsson [this message]
2013-09-18 17:00                 ` Colomban Wendling
2013-09-18 18:57                   ` David Henningsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5237776C.10000@canonical.com \
    --to=david.henningsson@canonical.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lists.ban@herbesfolles.org \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox