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

David Henningsson david.henningsson at canonical.com
Thu Jun 21 16:23:48 CEST 2012

On 06/21/2012 03:19 PM, Takashi Iwai wrote:
> 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.

It is always difficult to bet on the future, but sure, that's a 
drawback. So what were you suggesting instead, in a little more detail?

Maybe making "virtual" volume controls, that would only be affecting the 
node when the actual input is selected?

David Henningsson, Canonical Ltd.

More information about the Alsa-devel mailing list