[pulseaudio-discuss] Mic input volume controls

[David Henningsson]

On 2010-12-01 16:09, Colin Guthrie wrote:
> 'Twas brillig, and David Henningsson at 01/12/10 13:55 did gyre and gimble:
>> Hi folks,
>>
>> The way we control mic input is quite broken. I've tested here with both
>> IDT codecs and Realtek codecs (the two most common HDA Codecs AFAIK) and
>> as far as I see they're both broken in the same ways.
>>
>> Let's assume that we have an internal mic and an external mic jack, with
>> autoswitching in the kernel. We have a "Mic Boost" affecting the
>> external mic jack, a "Front Mic Boost" affecting internal mic, and a
>> "Capture" control affecting both.
>> "Mic Boost" and "Front Mic Boost" go from 0 to 60 dB in 20 dB steps, and
>> "Capture" goes from 0 to 22.5 dB in 1.5 dB steps.
>>
>> 1)
>> The first problem is PA is unable to combine both of them correctly: for
>> the first 0 to 22.5 dB, PA moves the "Capture" control only. After that
>> say at 25 dB, "Mic Boost" moves to +20 dB, keeping "Capture" at 22.5 dB,
>> then using softvol to compensate, instead of lowering "Capture". I've
>> been suggested that changing the order of "Mic Boost" and "Capture"
>> improves this situation, so we should probably do that. Any objections?
>
> With the "direction" argument passed to the relevant alsa calls as we
> currently have, swapping them around should indeed help here yes. No
> objection in principle for me. I guess we'll just statically swap them
> around for now? In theory, I guess the order of the "controlled element
> pipeline" could be dynamically adjusted so that biggest steps happen
> first... but this approach would possibly introduce unwanted side effets.

Hmm. I remember Lennart's original approach would have been to maximize 
signal quality (i e, move "Master" and let "PCM" stay at 0 dB). Moving 
this analogy to the input case, what would be the highest quality for 20 
dB - having "Mic Boost" at 20 dB and "Capture" at 0 dB, or "Mic Boost" 
at 0 dB and "Capture" at 20 dB?

To be honest, I'm not sure, but in theory I assume "Mic Boost" should be 
at 20 dB and Capture at 0 dB because the signal path between "Mic Boost" 
and "Capture" would be stronger.

Let's play with the idea that we added a configurable "Direction" key to 
these profiles that controlled whether we moved up or down to the 
nearest step. Wouldn't that help? Then we could have "Mic Boost" first 
in chain, then set it to move down rather than up.
Or maybe that we should instead say that if we're above 0 dB, we move 
down, and if we're below 0 dB, we move up? Would that make sense?

>> 2)
>> The harder problem is that PulseAudio does not know whether to control
>> "Mic Boost" or "Front Mic Boost", since it doesn't know what path is
>> active at the moment. While we really need some kind of module, and
>> appropriate kernel support, the question is what we do before that
>> becomes sufficiently available. The next best solution, would probably
>> be to have different profiles and manual autoswitching. While I yet have
>> to look into the details, I guess we'll have to add different profiles
>> for "Mic", "Front Mic", "Rear Mic" and so on, instead of having them in
>> the same file as we have today. Any thoughts?
>
> I guess splitting them out makes sense so as to keep the pipeline for
> each clean. Would you still envisage keeping each mic as a separate
> port?

Hmm, what does "port" mean in this context? Since we might have to 
control different pipelines, I don't see how we can have it in the same 
profile.

> (I guess the only other option would be to check if both mics
> could be opened at the same time in the profile probing to allow for two
> alsa-sources to be loaded at the same time. But that's likely going to
> lead to a lot of other problems,

Agreed; let's avoid more than one alsa-source at this point even if it's 
possible for some codecs.

> so perhaps best to leave that until UCM
> can just tell us without probing).

After having spoken to Mark Brown at Plumber's, he does not expect UCM 
to handle HDA stuff in the near future, it will be something for the 
embedded world primarily and we will still have to rely on PA's mixer 
paths. So unfortunately, I wouldn't hope for UCM to be our great problem 
solver.

>> 3)
>> It'd be great if we could present something else than "Microphone 1",
>> "Microphone 2" and so on when we have more than one mic input. Any idea
>> of where this name actually comes from, and how we can make it better?
>
> I think ultimately from the table in ./modules/alsa/alsa-mixer.c
>
> There is a difference between internal and external microphones, so I
> guess making the distinction between front and rear and such like
> wouldn't hurt anyway... that said, WTF is the diffrence between a front
> and rear mic physically on a laptop? Do they *really* make laptops with
> two mics on them for this purpose? (from the names I'd have to expect a
> yes answer there, but seeing as my laptop has no built in mic, I'd say
> having two is just showing off :D)But more seriously, why are there
> front and rear mics? Is this for>stereo recording? If so should these
> inputs be handled as a single, multichannel source rather than separate
> mono or stereo ones? I mean we don't expose the "Rear" playback so why
> do we do it on mics? As you can tell, my foo for recording is rather weak :D

In addition to Mark's answer: This is all a mess; perhaps the biggest 
mess we currently have at the ALSA/PulseAudio layer today.

A quite common laptop today has a built-in mic and a mic jack. The mic 
jack is usually labeled "Mic", but the built-in is sometimes labeled 
"Front Mic", sometimes "Internal Mic" (there is also "Digital Mic", 
"Internal Mic 1", "Int Mic" and other crazy stuff in there...).

Desktop computers often have two mic jacks, one at the front, one at the 
rear, and they are (sometimes!) called "Front Mic" and "Rear Mic".

So now "Front Mic" can sometimes mean an external mic and sometimes an 
internal one. Also, in the desktop, I'd would be helpful to know the 
location of the jack. So my suggestion would be to add an 
input-microphone-front to alsa-mixer.c as well as fix an input path for 
this. Do you agree?

Now we haven't even started thinking about microphone arrays; but since 
you brought it up: AFAIK, there is no support for using microphone 
arrays to reduce noise from internal mics in Linux, as there is in 
Windows Vista and Windows 7. But if anyone with some knowledge of the 
DSP algorithms behind would be willing to write such a PulseAudio 
module, that would be very nice. Maybe a good candidate for a GSoC 
project or so?


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