[alsa-devel] [RFC] Fix internal mic for Lenovo Ideapad U300s
tiwai at suse.de
Sat Apr 7 12:37:44 CEST 2012
At Mon, 02 Apr 2012 15:39:30 +0200,
David Henningsson wrote:
> 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
> >> anyway.
> >> 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
> separate email.
> > 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?
Yeah, some code reorganization would be needed in near future.
More information about the Alsa-devel