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
