Comment 40 for bug 441195

@Daniel et al.

This is not a driver bug. I investigated the driver and hardware a lot and discussed the issue in an ALSA bug report: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=5031 As you can see in my last comment, I have requested that my "bug" report be closed, because I decided that ALSA is working correctly.

The STAC 92xx chipset has two hardware volume controls, one for the L/R channel and one for the subwoofer (LFE) that is derived from L+R. But neither hardware volume affects the other. The so-called "Master" only affects the stereo internal speakers. It has no effect on the LFE volume. That's just how the chip is designed. :(

The job of ALSA kernel drivers is to present an interface to what the hardware implements, so it is doing the right thing. AFAIK there is no social contract in ALSA that a hardware volume control named "Master" is multiplied with all others. If there were then it would be a design flaw, because there is nothing to stop chipset developers from making a product that is incompatible with that, as we are seeing here. It is not reasonable for the Linux kernel to attempt to provide functionality that does not exist in the hardware.

To fix this issue, PulseAudio needs to either change the LFE volume in sync with the Master volume or use the PCM softvol exclusively, which is the work-around that I have adopted by adding "load-module module-alsa-sink control=PCM" to default.pa. The PCM approach is sub-optimal though because a software volume presumably incurs quantization error at low volume levels.

See also the upstream bug at http://pulseaudio.org/ticket/457

I do agree though that it would be nearly impossible to work around this in PulseAudio and have it work for all hardware. I think the best solution would be for PA to have a blacklist of chipsets with dumb volume control designs and simply use the PCM control for them exclusively.