[pulseaudio-discuss] Mic input volume controls
david.henningsson at canonical.com
Thu Dec 2 02:38:08 PST 2010
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.
>> 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?
>> 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
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
> (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
>> 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.
More information about the pulseaudio-discuss