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