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

[Takashi Iwai]

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
> 
> 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?

AFAIK, no, it was specific to the codec model.

> >>>> 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.

It should work no matter whether the right channel is muted or not.
The plug layer will use only the left channel when a mono stream is
recorded since route_policy=copy is set.  Remember that it's about
"default" PCM, not about "hw" PCM that PA uses.  We don't touch "hw"
intentionally because it's really intended to be a raw access.

> 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.

It's actually already handled in ALSA.  It's just PA that ignores it
via "hw" PCM :)  Of course, I don't mean that the handling in alsa-lib
config is perfect, and it's a workaround.

> 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.

Yes, that's the problem.

> > 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...

Yes.  I don't think it's appropriate, too.


Takashi