Re: [RFC PATCH] Inverted internal mic

[David Henningsson <david.henningsson@canonical.com>]

On 02/28/2012 11:38 AM, Takashi Iwai wrote:
> At Tue, 28 Feb 2012 10:54:00 +0100,
> David Henningsson wrote:
>>
>> On 02/28/2012 10:24 AM, Takashi Iwai wrote:
>>> At Tue, 28 Feb 2012 09:57:56 +0100,
>>> David Henningsson wrote:
>>>>
>>>> Hi,
>>>>
>>>> One of the more common problems on laptop machines, is that the internal
>>>> mic provides a stereo signal but with one channel phase inverted, or
>>>> differential output.
>>>>
>>>> This means problems for applications recording two channels but later
>>>> merging them into one, leaving them with zero or near-zero output.
>>>>
>>>> There are various ways we can work around this in both the kernel,
>>>> alsa-lib and PulseAudio layers. It's a matter of picking the right one.
>>>> I'm leaning towards trying to fix it in the kernel's codec drivers, because
>>>> 1) we already have quirking infrastructure there
>>>> 2) we already have some working quirks already in that layer
>>>> 3) it would benefit other sound applications that use ALSA directly.
>>>>
>>>> The downside to that is really that we're silencing out one channel for
>>>> everyone, leading to no application being able to use both channels,
>>>> even if they would implement some kind of
>>>> "auto-detect-and-reverse-one-channel" functionality.
>>>>
>>>> For the most part, this has been some Acer Aspire machines running
>>>> Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we
>>>> have proc coefs we can set, but for the other two these proc coefs, if
>>>> they exist, are unknown to us.
>>
>> A follow-up question here would be if it is easy for you (or Kailang?)
>> to figure this out, or if we should resort to the suggest workaround for
>> Realtek ALC268 and ALC272X as well?
>
> Actually, Kailang (Cc'ed now) and I talked about it when I visited
> Taipei in the last year, and he mentioned that there is no way to
> detect the FM chip from the codec.  It seems that SSID listing is the
> only way.

Ok. My question was more about the following: When I look at 
patch_realtek.c, I can find functions alc271_fixup_dmic and 
alc269_fixup_stereo_dmic. I have also seen machines having ALC268 and 
ALC272X that have this internal mic behaviour. Is there a way we can 
know the corresponding processing coefficients to set for ALC268 and 
ALC272X as well?

>>>> Recently I came across a Conexant as well, and I decided to write a
>>>> patch for it, that would take the approach that the internal mic is
>>>> forced mono on the kcontrol, and make sure the right channel is always
>>>> muted. The patch is verified by the reporter to fix this problem. It
>>>> could use some perfection though - it would make sense to to the same to
>>>> the internal mic boost as well, and the strcmp('Internal Mic') call
>>>> could maybe be turned into something more elegant. But before going
>>>> ahead with that, I'd like to hear your opinion on the matter, if you
>>>> agree that this is a good approach to the problem?
>>>
>>> The remaining problem in the patch is that the signal is recorded only
>>> on left when you record in stereo.  I guess the reporter tested only a
>>> program like Skype, which uses only a mono stream.
>>>
>>> If this behavior, only one channel in a stereo stream, is acceptable,
>>> it's a reasonable fix, I think.
>>
>> That is indeed a disadvantage, but I don't know if we have something
>> better to offer? E g, we could try an alsa-lib ttable solution, but that
>> would then have a problem with knowing whether the Internal Mic is
>> currently selected or not.
>
> Note that in alsa-lib, the HD-audio "default" is already set up to
> copy left-channel for mono streams.  You can see a line setting
> "route_policy" to "copy" in HDA-Intel.conf.
>
> Thus, when ALSA apps run without PA, it'd work in both stereo and
> mono.

Assuming the right channel is muted, yes. But not in the current 
implementation.

By not making a change in the ALSA layer, it will still be broken for 
any ALSA apps who record the Internal Mic as a stereo signal. They will 
get a broken result as the right channel will be phase inverted. That's 
why I think this is better dealt with in the ALSA layer.
Would a zeroed right channel be less broken than a phase inverted right 
channel? I think so.

>> If the program:
>>
>> - tries to record in mono:
>>     * As the industry standard for mapping mono is to map it to the left
>> channel, I assume this is what ALSA/HDA does in this case as well, so
>> unchanged and working behaviour
>>
>> - record in stereo, then take left channel only:
>>     * unchanged and working behaviour
>>
>> - record in stereo, then take right channel only:
>>     * regression as the inverted channel will now be zero, but this would
>> be highly unconventional and unusual, I assume?
>>
>> - record in stereo, then merge both channels:
>>     * this is the normal and common case for VoIP applications going
>> through PulseAudio (Skype etc). Improvement, this will fix the bug;
>> although the result will be -6 dB compared to the original signal.
>>
>> - record in stereo, keep signal in stereo for playback:
>>     * this somewhat depends on how the playback is set up, but I would
>> say that it would be an improvement in most cases if the speakers are
>> relatively close to one another...I guess?
>
> Well, I think this could be also worked around in PA.  Can PA switch
> the downmixing to the mono to a simple left-channel copy, only for
> certain devices, or at least via a config?
>
> If this is feasible, the rest is how to identify such a device.
> And this can be done equally well in user-space, too, as there is no
> hidden information about it.

PA has udev rules to identify the device, so I'm not too worried about 
the identification, though that is generally frowned upon - I'd say that 
hardware dependent stuff should be in ALSA rather than PA. The 
difficulty is that we need to switch this on and off when we switch 
ports - we don't want to regress behaviour for e g line in and other 
stereo recording sources.

> Of course, this is not the best of the best.  Ideally, the driver
> provides multiple PCM streams and PA switches between them and
> switches the downmixing simultaneously per input-source change.
> But this needs a lot of works, and maybe requires a fundamental
> infrastructure change, too.

Seems almost easier to write a PulseAudio module that automatically 
detects when one channel is phase inverted, and inverts that channel 
when that happens. But maybe that is ugly too...

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