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

David Henningsson david.henningsson at canonical.com
Tue Feb 28 14:07:59 CET 2012

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 

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.

More information about the Alsa-devel mailing list