[pulseaudio-discuss] Mic input volume controls

[David Henningsson]

On 2010-12-04 19:09, Colin Guthrie wrote:
> '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).

We want to maximise quality while avoiding digital distortion, that's 
basically the problem in a nutshell. We're assuming (sometimes 
incorrectly; but that's our best guess) that this golden spot will be 
achieved with all sliders at 0 dB.

I think my approach makes sense, unless I'm missing something: If we're 
aiming for something above 0 dB, let's round down to make sure we avoid 
distortion, and if we're below 0 dB, let's round up to make sure we get 
maximum quality.
And then we always start with the control that's closest to the physical 
hardware and work our way in.

What's in and out here; that's currently determined by the order in 
which PulseAudio reads them in, right? That complicates matters a little 
given the include file structure and so I'm thinking maybe we should add 
a "extremity=<number>" key to the config file? (This is unrelated to the 
direction key suggested previously.) We would then start with the one 
having the highest "extremity" score.

Otherwise we would get in trouble if we have a profile with a volume 
control B (with extremity=2), which then includes a file with both 
control A (with extremity=1) and control C (with extremity=3) in the 
same include file.

I think that would actually make things clearer. What do you think?

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

I think the most common case is that the different mic inputs are 
connected at the codec level, which means that we control mic input 
selection and levels via volume controls only and there's only one 
channel in.

Quite common is also that we have two ADC's in from the codec that can 
be used in parallel, exposed through ALSA as different subdevices - this 
is not currently possible to set up in PA without manual configuration, 
and my proposal does not change that.

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

Cool.

>> 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 noisefrom 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 :)

Could also be worth investigating if someone has already written 
something like that for Jack/Ladspa/LV2/something, in which case it 
could be ported to PA.

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