[pulseaudio-discuss] Mic Boost on AC97 audio causes bad behavior of mic volume control

[Wilck, Martin]

On Mi, 2015-04-29 at 19:17 +0300, Tanu Kaskinen wrote:

> > The graphical volume controls don't reflect this; thus user control
> > input volume is almost impossible at higher levels than 25%. Volume will
> > appear to change non-predictably to users.
> 
> PulseAudio compensates coarse hardware volume by applying software
> volume when necessary. This means that users get a smooth volume curve.
> For example, you presented a nice table of different volume levels, and
> there was this line:
> 
> PA(%)   PA(dB)  Captu   Boost   Capture+Boost-66dB
> 56%     -15.00  30.00   12.00   -24.000000
> 
> The ideal situation would be where the second and the last column would
> be equal, but in this case there's a 9dB difference. But no worries,
> PulseAudio compensates that by amplifying the signal by 9dB in software.

OK, I didn't know that. Thank you. I still think that Pulseaudio should
rather apply the hardware volume control in "coarse first, fine later"
order, eliminating the need for software volume compensation (which
would infer distortion unless I am mistaken).

> Did you observe some volume problems by ear, or did you only notice
> "weird behaviour" by looking at the alsa mixer?

I did observe something by ear, but it's a long story. Since you asked
for it, the full story is related to
http://lists.nongnu.org/archive/html/qemu-devel/2015-04/msg02271.html,
and goes like this:

I (have to) run Microsoft Lync for telephone conferencing in a Windows
guest on Qemu/KVM under Linux. I use Qemu's spice audio protocol to link
my sound sources/sinks to the Windows guest. The Windows guest sees an
emulated Intel HD Audio codec (ICH6 or ICH9) that has a 74dB volume
scale for capture. For unknown reasons, Windows uses only the upper
~30dB. Therfore setting the Windows volume slider to 1% lets the "HW"
volume in the emulated HD audio chip jump ~40% immediately. See the
above qemu-devel post for details.

The libvirt spice server communicates this percentage  to PA. PA is
using the "48dB Capture + 36dB Boost" = 84dB volume scale. Setting this
to 40% results in Capture=+30dB (maximum) and Boost=+12dB. Again, this
happens if I set just 1% volume under Windows, about the lowest possible
setting!

Microsoft Lync, in turn, has the unpleasant habit to try and regulate
input volume automatically. This fails utterly because a minimal change
in the windows guest causes the HW volume to jump back and forth. The
end result was that my phone peers complained about miserable sound
quality (noise) on my part. Basically I had to stay mute.

This problem is caused by a combination of various things:
 1) the weird behavior of the windows volume control, and the fact that
Lync's auto-volume-adjustment can't be switched off
 2) the unrealistically large volume scale of the emulated "Capture"
device in QEMU
 3) the fact QEMU doesn't have a "dB" volume scale, rather all controls
work in arbitrary "percentage" units
 4) the merging of "Capture" and "Boost" by PA, blowing up the volume
scale from 48dB to 84dB.

By now, I have combined various measures in order to work around this
problem:

 - for 4): Using a fixed value for "Mic Boost" in PA makes the overall
volume scale of the input control smaller, mitigating the problem
 - for 4): Switching off PA's "flat volumes" avoids Lync->Windows
guest->QEMU->spice->PA cranking up the hardware volume control of the
host
 - for 2): I applied a QEMU patch (see thread above) to present a
smaller, more realistic Capture amplifier to the guest, but that patch
has been rejected by the QEMU folks so far because it's a guest-visible
change.

This yields a big improvement. I can't do anything about 1), and fixing
3) would be project too large for me at the moment.

While I was pulling my hair trying to understand what happened in this
complex scenario, I found the volume control strangeness that I have
tried to report here. If only that was fixed by reverting commit
e6051cdf, the volume control would at least behave more "smoothly". It
wouldn't suffice to fix my problem though.

Martin