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
