[pulseaudio-discuss] Mic input volume controls

Sat Dec 4 10:09:31 PST 2010

'Twas brillig, and David Henningsson at 02/12/10 10:38 did gyre and gimble:
> 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?

I would agree that using the "highest quality" pipeline is probably the
best approach, but I'm afraid I also have no idea how to determine which
approach is higher quality!

My logic of "putting the biggest steps first" was really just to
maximise using alsa controls rather than falling back to our own
adjustments in software. This just "seemed sensible" but there could
very well be quality arguments against it (I wouldn't want my PCM to be
favoured over my Master for playback for example as the former is softvol)

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

I'm not really sure here. A specific direction key may complicate what
is already a rather complicated thing, so if we can possibly do things
sensibly without it, then I'd suggest that would be more attractive (if
it works reliably enough).

>>> 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 was meaning the port as in the current port of the source in PA speak.
I thought that different ports had different pipelines already so don't
really understand why they need to be separate profiles.

Perhaps I'm not understanding "profile" in this context. Your original
quote seemed to suggest a profile meaning a specific file in the
alsa-mixer tree, but in the latest one seems to suggest "card profiles"
(e.g. Stereo Duplex etc.)

Perhaps I've just not understood properly here :D

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

Yeah I think this makes sense.

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

Interesting. I'm not really clued up on all this jazz, but it does sound
like a good GSoC possibility :)

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]