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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
