[alsa-devel] Help wanted: emachines em350 internal mic

[Takashi Iwai]

At Tue, 07 Dec 2010 16:11:59 +1300,
Eliot Blennerhassett wrote:
> 
> Thanks Raymond,
> 
> On 03/12/10 15:33, Raymond Yau wrote:
> >>> Greetings,
> > 
> > 
> >>> There is only a single mic on this netbook. However, the alsa device
> >>> shows up as stereo, and the right channel carries an inverted copy of
> >>> the left channel.
> > 
> > http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=59c774ed5ee00e9623a204c3234191d6a6d8cf7a
> 
> Commitlog was "Add route_policy copy to HDA-Intel.conf for capture
> Since some digital mics have the phase-inversion problem in one channel,
> adding both channels for mono stream results in the noise. Use
> route_policy copy to avoid that situation."
> 
> As far as I can guess, the commit helps when an application asks to
> record mono from the stereo device, by copying L rather than summing L+R
> 
> My machine already has this, however it doesn't really fix the root of
> the problem.
> 
> Because the internal mic appears as a stereo device, rather than a mono,
> applications can open it as stereo.
> 
> Only later when the resulting signal L+R is sent to a mono output does
> the signal "disappear".
> 
> So I'm back to wondering how to force an app (primarily PulseAudio) to
> see the mic as mono?

Via pulse configuration?

> (I think the external jack is also only mono, at least when used as a
> mic input?)

I'm not sure about it.  Many devices are indeed stereo mics,
especially with HD-audio.


The problem is that you seem to have a PDM module for digital mics
by FortMedia, which shows this behavior.  I guess this was primarily
for noise canceling.  For Windows, FM provides a special driver, so
this was handled there.

In the case of ALSA, it's not quite easy.  Since the hardware really
gives the stereo signal, and this isn't informed to the software side
at all, the upper layer can't know it.  And, reverting in the kernel
side doesn't sound right, if it's only about PA.  (Non-PA stuff has
already a 'workaround'.)

So, we need a few steps:
 - Implement a kernel ABI to inform some h/w feature like this
 - Implement alsa-lib API to propagate it
 - Implement the handling in PA alsa module


Takashi