[pulseaudio-discuss] Mic input volume controls

[Colin Guthrie]

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

> 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? (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, so perhaps best to leave that until UCM
can just tell us without probing).

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

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