Debugging Bad dB Information of ALSA Drivers

If (when flat volumes are enabled in PulseAudio) the playback volume of one stream changes whenever another stream is played, this is most likely caused be incorrect dB attenuation data exposed by the ALSA kernel driver.

To debug and verify that via a listening test, use the "dbverify" tool from by "dbmeasure" tool set:

http://git.0pointer.de/?p=dbmeasure.git
git://git.0pointer.de/dbmeasure.git

The tool requires only minimal dependencies: besides the libc headers only the alsa headers. It is independent of PulseAudio. After a git checkout and a "make", you may run dbverify like this:

$ ./dbverify Aureon51MkII Master 30 200

This will test the dB data of the "Master" mixer control of the "Aureon51MkII" sound card for the mixer volume steps 30 and 200 (note that this assumes you have at least 200 volume steps. How many you have depends on hardware and driver. See below). The list of sound card ids for the first parameter you may find by issuing:

$ cat /proc/asound/cards

The ALSA card ID string is enclosed in []. Instead of card names you may also use ALSA card indexes as first parameter to dbverify. The list of suitable mixer controls for the second parameter of dbverify you may list with:

amixer -D hw:Aureon51MkII | grep "Simple mixer control"

If the third and fourth parameter to dbverify are ommited, the tool will test the loudest volume setting against the softest one. If those arguments are specified the tool will compare these two discrete volumes. It is advisable to play around with these values to compare multiple volume steps of the hardware. It is especially wise to pick your own values if the lowest hw volume setting is too silent to be audible. That said it might make sense to omit these arguments when starting your testing. This will then also show you the available volume step range of your card and you can then pick other values to tes from that range.

The tool will play a 1s sine wave twice and in a loop, and attenuate it once in software and once in hardware. The effect should be that the wave should have the same volume both times if the dB information is reliable. If the dB data is not correct, then they will have different volumes.

The command line mentioned above will test the "Master" mixer element of your card. Of course, usually this is not the only mixer element in the audio pipeline, which means after you tested "Master" you might want to test "PCM" and "Speaker", too, and possibly others ("Front", ... the available controls depend on the card and driver).

If this listening test reveals that the dB information of your driver is not correct, then please file a bug on your respective distribution bug tracker or the kernel bugzilla (and NOT the PulseAudio bug tracker!). If you want to help even more then consider measuring the correct dB data for your card. Use the dbmeasure tool from the same git repo for that. You'll need a loopback cable for that to connect line out with line in, a lot of time and a little bit of technical expertise. For more details see the README of dbmeasure. Make sure to file a bug in your distributions bug tracker/kernel bugzilla and ask for your data to be included as a quirk update for your driver (that means also include the output of alsa-info.sh --no-upload in that bug report).

There's a temporary workaround to make PA skip the invalid dB data. But ha! I won't write down how that works here, to make sure that you really file that bug. Muahaha. Mauahahahahah!

Also see the original announcement mail for dbverify!