[alsa-devel] [RFC] Fix internal mic for Lenovo Ideapad U300s
david.henningsson at canonical.com
Mon Apr 2 15:39:30 CEST 2012
On 03/30/2012 04:31 PM, Takashi Iwai wrote:
> At Thu, 29 Mar 2012 22:48:20 +0200,
> David Henningsson wrote:
>> The internal mic input is phase inverted on one channel.
>> To avoid people in userspace summing the channels together
>> and get zero result, use a separate mixer control for the
>> inverted channel.
>> BugLink: https://bugs.launchpad.net/bugs/903853
>> Signed-off-by: David Henningsson<david.henningsson at canonical.com>
>> Inverted Internal Mic, take 2.
>> I refined my idea a little. By calling the left channel "Internal Mic"
>> and the right channel "Inverted Internal Mic", we're giving the user a choice
>> whether to activate it or keeping it muted.
>> For PulseAudio, the quick fix is just to make sure the "Inverted Internal Mic"
>> control is muted. If we in the long run want to actually handle this and swap
>> the phase around, we now also have a reasonable indicator if we should do this,
>> by checking if the "Inverted Internal Mic" control exists.
>> For the ALSA init DB (i e, should the "Inverted Internal Mic" be initially muted?)
>> that is no big deal for me, since this will be overwritten by PulseAudio later
>> I'm also open for better names than "Inverted Internal Mic" if you have any.
>> As with the previous version, this is a draft version of the patch, and could be
>> done slightly more elegant I guess.
>> What do you say?
> Good, this sounds like a reasonable solution.
I'm happy you like it!
> About the name, I'm not sure, too. I'm no good godfather.
> Maybe other people have a better clue.
> Once when the patch is finialized, let me know.
I've been working with it today, and I'm sending a new patch in a
> I think we clean up the fixup functions by moving the alc_fixup_*() as
> common functions. ALC_FIXUP_SKU can be converted to an ALC_FIXUP_FUNC,
> then there is no Realtek-specific things there.
I'm happy for all consolidating between codec drivers. Perhaps this
could be a good start for a new hda_auto.c file that separates the
low-level communication in hda_codec.c, from the auto-parser related
stuff which could reside in hda_auto.c?
David Henningsson, Canonical Ltd.
More information about the Alsa-devel