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

[Takashi Iwai]

At Thu, 21 Jun 2012 15:04:44 +0200,
David Henningsson wrote:
> 
> On 06/21/2012 02:52 PM, Takashi Iwai wrote:
> > 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.
> 
> Yes, this logic can only be used when there are two inputs - mic and 
> internal mic. That is, the same conditions we today have for determining 
> when to have auto-switching on plug/unplug.
> 
> Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would 
> be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used 
> (unless we try to implement some kind of vmaster on the input side, but 
> I don't think that would be necessary).
> 
> The alsa-info's I've looked at so far all have had one internal mic and 
> one external mic on the input side. At least the Realtek ones.

Well, it's a bit risky to bet that.  I won't be surprised by any
largish machines with one more jack for supporting 5.1 output and a
digital built-in mic, for example.


Takashi