In recent versions PulseAudio integrates the numerous mixer elements ALSA exposes into one single powerful slider which tries to make the best of the granularity and range of the hardware and extends that in software so that we can provide an equally powerful slider on all systems. That means if your hardware only supports a limited volume range (many integrated USB speakers for example cannot be completely muted with the hardware volume slider), limited granularity (some hardware sliders only have 8 steps or so), or no per-channel volumes (many sound cards have a single slider that covers all channels), then PulseAudio tries its best to make use of the next hardware volume slider in the pipeline to compensate for that, and so on, finally falling back to software for everything that cannot be done in hardware. This is explained in more detail here.
Now this algorithm depends on that we know the actual attenuation factors (factors like that are usually written in units of dB which is why I will call this the "dB data" from now on) of the hardware volume controls. Thankfully ALSA includes that information in its driver interfaces. However for some hardware this data is not reliable. For example, one of my own cards (a Terratec Aureon 5.1 MkII USB) contains invalid dB data in its USB descriptor and ALSA passes that on to PulseAudio. The effect of that is that the PulseAudio volume control behaves very weirdly for this card, in a way that the volume "jumps" and changes in unexpected ways (or doesn't change at all in some ranges!) when you slowly move the slider, or that the volume is completely muted over large ranges of the slider where it should not be. Also this breaks the flat volume logic in PulseAudo, to the result that playing one stream (let's say a music stream) and then adding a second one (let's say an event sound) might incorrectly attenuate the first one (i.e. whenever you play an event sound the music changes in volume).
Incorrect dB data is not a new problem. However PulseAudio is the first application that actually depends on the correctness of this data. Previously the dB info was shown as auxiliary information in some volume controls, and only noticed and understood by very few, technical people. It was not used for further calculations.
Now, the reasons I am writing this blog posting are firstly to inform you about this type of bug and the results it has on the logic PulseAudio implements, and secondly (and more importantly) to point you to this little Wiki page I wrote that explains how to verify if this is indeed a problem on your card (in case you are experiencing any of the symptoms mentioned above) and secondly what to do to improve the situation, and how to get correct dB data that can be included as quirk in your driver.
Thank you for your attention.