[alsa-devel] [RFC PATCH] Inverted internal mic

Takashi Iwai tiwai at suse.de
Thu Jun 21 14:52:41 CEST 2012


At Thu, 21 Jun 2012 03:15:27 +0200,
David Henningsson wrote:
> 
> On 06/20/2012 03:31 PM, Takashi Iwai wrote:
> > At Tue, 19 Jun 2012 09:43:07 +0200,
> > David Henningsson wrote:
> >>
> >> On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
> >>> David Henningsson<david.henningsson<at>   canonical.com>   writes:
> >>>> On 02/28/2012 02:22 PM, Takashi Iwai wrote:
> >>>>> At Tue, 28 Feb 2012 14:07:59 +0100,
> >>>>> David Henningsson wrote:
> >>>>> Is there a way we can
> >>>>>> know the corresponding processing coefficients to set for ALC268 and
> >>>>>> ALC272X as well?
> >>>>>
> >>>>> AFAIK, no, it was specific to the codec model.
> >>>>
> >>>> Ok, then we can only hope for Kailang to supply this information if
> >>>> possible. And if not possible we could attempt the workaround (when/if
> >>>> we agree on it...) for these devices as well?
> >>>
> >>> Greetings,
> >>>
> >>> Any chance that there has been any progress on this?
> >>> I have a machine with dmic and ALC272X (details below) that exhibits this
> >>> problem, and can test any proposed patch.
> >>
> >> We have a patch in for the Thinkpad U300s, but that one had a Conexant
> >> codec.
> >> I haven't had time to start working on kernel patches for the Realtek
> >> ones yet, but meanwhile, I'm tracking known machines here:
> >>
> >> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
> >
> > Looking at the codec, it's not so trivial to port the inverted switch
> > to Realtek.  In the input path of Realtek codecs, there is no
> > individual capture volume/switch but only a central ADC volume and a
> > MUX (or a mixer).
> 
> Yeah, that's part of why I haven't done it myself yet ;-)
> 
>  > I can think of a new boolean switch or an enum to choose whether to
>  > shut off the right channel of the input-mux and the loopback volume.
>  > But it's feasible only if it make sense to PA.
> 
> It seems possible that for ALC269 [1], you could switch path entirely 
> (including ADC). I e, the internal mic would go 0x12 -> 0x23 -> 0x08 and 
> the external mic would go 0x18 -> 0x24 -> 0x07. That way you could then 
> label the volume control on 0x08 "Internal Mic Capture Volume" and 
> "Inverted Internal Mic Capture Volume".
> 
> Do you think this is a good strategy, or would it lead to other problems 
> (i e, what happens when you plug your mic in while actively recording)?

If the i-mic is the only user for ADC 0x08, this would work.
But when ADC 0x09 has multiple sources like e-mic and line-in,
ADC 0x09 would be named as "Capture" (because it's not only "Mic"),
and this becomes exclusive with "Internal Mic Capture".  It's a bit
confusing, IMO.


Takashi


More information about the Alsa-devel mailing list