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

[David Henningsson]

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.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic