From: David Henningsson <david.henningsson@canonical.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org,
Colomban Wendling <lists.ban@herbesfolles.org>
Subject: Re: Fwd: Re: Realtek ALC889: HDA Intel and kernel 3.1 gives choppy sound (again)
Date: Tue, 20 Dec 2011 00:03:51 +0100 [thread overview]
Message-ID: <4EEFC2D7.3020003@canonical.com> (raw)
In-Reply-To: <s5hd3bkk294.wl%tiwai@suse.de>
On 12/19/2011 04:30 PM, Takashi Iwai wrote:
> 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.
>
> BTW, maybe we should turn off the jack-detection while the auto-mute
> is disabled? Otherwise unsol events might still come up although they
> are just ignored.
I guess that would also disable the possibility for userspace to read
state changes, both with the old and new jack detection interface?
Also, in a long term scenario, one could consider PulseAudio disabling
auto-mute and handling that logic itself, potentially with advanced
routing rules (a use case could be, if a phone call comes in, play the
ring tone in the speaker but the actual talking would be through the
headset).
--
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic
next prev parent reply other threads:[~2011-12-19 23:03 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 [this message]
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
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=4EEFC2D7.3020003@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 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.