pulseaudio master volume is scaled differently as alsa master

[yelo3]

I'm running ubuntu karmic and currently the pulseaudio version is 0.9.15-3ubuntu1. I've noticed that when I increase or decrease the alsa volume, the pulseaudio volume is increased/decreased by a different amount.

In particular when alsa master is 0%, pulseaudio master is 40%. Instead they are 100% at the same time.

if you need some information about log files and card models, pulse and alsa versions, in this bug there's everything you need.

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/366603

[lennart]

This is intended that way. The volume scales align based on the dB scale. The percentage scale is completely artificial and should not be used to match things up.

[yelo3]

0.9.18-0ubuntu3

Now the volume is muted at 15%.

I'm sorry to reopen this bug, but I can't understand why you think it is normal to have the volume muted at a percentage different from 0%

[lennart]

% volumes are artificial, they have no defined meaning, in every context they are differently defined.

As I already mentioned, our entire logic is based on the dB scales. So if your audio is already muted at a level where you don't think it should be muted, then please use "alsamixer -c0" and check the dB values for that mixer state. Probably a relatively high dB values is exposed for a volume where audio is already completely cut off. If that's the case, then the dB data your driver exports needs to be fixed. Please file a bug against your audio driver for this, and include the data from "alsa-info.sh --no-upload" there, plus the output of "amixer -c0" configured to a state where the dB information suggests that you should still hear audio, but you actually don't.

[yelo3]

I need your help again, since I'd like to fix this bug, and file a bug against my audio driver. I run alsamixer -c0 and it prints db gain=-48.00

My question is: how can I know which dB value should be mute, instead of -48dB?

[lennart]

Consider reading up on decibel on wikipedia:

http://en.wikipedia.org/wiki/Decibel

Basically, if the signal is completely cut off, then the attenuation is -inf dB.

[yelo3]

I opened a bug to alsa, and someone answered that this might be a problem in pulseaudio. Here's a link to the bug, so you can read the comments: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4956

[yelo3]

In the ALSA bug there was a question that they need to know to understand if the problem is in ALSA:

"if 0% of pulse ctl device is -inf dB and 100% is 0dB , the pulse mixer control has 65536 steps you have to ask PA developer each step of the pulse mixer represent how many dB"

[yelo3]

I've done other tests and I noticed that when I move the volume under 5% (in PA), the alsamixer shows that PCM volume is decreased, and does 3 steps (the whole red, white and green) if I get the volume lower to 0%

[yelo3]

I think that a pulseaudio developer needs to interact with the ALSA bug, since there are lots of technical informations about what might be the problem in pulseaudio: see this bug link https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4956

[yelo3]

Another quote from the alsa bug

Refer to HD audio specification

The theoretical possible maximum dB range of HDA codec is -32dB/step x 128step = -4096dB which is much larger than -inf dB and 0dB is defined by the offset , so it is wrong for PA developer to assume the minimum dB of the HDA codec volume control is -inf dB

7.3.4.10 Amplifier Capabilities

The “Amplifier Properties” parameters return the parameters for the input

or the output amplifier on a node. In the case of a Pin Widget, the terms input and output are relative to the codec itself; for all other widgets, these terms are relative to the node. The amplifier capabilities are indicated by the step size of the amplifier, the number of steps, the offset of the range with respect to 0 dB, and whether the amplifier supports mute.

StepSize? (7 bits) indicates the size of each step in the gain range. Each

individual step may be

0-32 dB specified in 0.25-dB steps. A value of 0 indicates 0.25-dB steps,

while a value of 127d indicates a 32-dB step.

NumSteps? (7 bits) indicates the number of steps in the gain range. There

may be from 1 to 128 steps in the amplifier gain range. (0d means 1 step, 127d means 128 steps). A value of 0 (1 step) means that the gain is fixed and may not be changed.

Offset (7 bits) indicates which step is 0 dB. If there are two or more

steps, one of the step values must correspond to a value of 0 dB. The “Offset” value reflects the value which, if programmed in to the Amplifier Gain control, would result in a gain of 0 dB.

Mute Capable (1 bit) reports if the respective amplifier is capable of

muting. Muting implies a –infinity gain (no sound passes), but the actual performance is determined by the hardware.

[coling]

If I'm perfectly honest, none of the core alsa developers even look at the alsa bug tracker. All you get is cryptic and misleading comments from some guy named Raymond.

This sounds like a classic case of invalid dB data in your driver. Lennart wrote about this recently: http://0pointer.de/blog/projects/decibel-data.html

I'd try and discuss the issue on the alsa-devel mailing list and give the results of the above measurements there. This is likely the only way to get the bug fixed in the driver. Typically it's more useful to file a bug against your audio driver in your distro as the distro guys will often be able to fix and push upstream after you've tested - where as the upstream guys will have to get you to build your own kernel to test any fixes they come up with. Hence why it's generally recommended to go through your distro if at all possible.

I doubt that there is anything in PA that needs to be fixed to address this problem.

[yelo3]

Thanks for your answer coling, I've already opened a bug in my distribution, but maybe what's missing is how I can identify if the decibel data exposed in ALSA is wrong.

Then I'd like know what exactly should I write in the alsa-devel mailing list, because I think I'm missing the point. Thanks

[yelo3]

Just a question: did you read all the comments in the ALSA bug?

[yelo3]

The "unknown" reported just pointed out that when the volume is set to 0% alsa can't report -inf dB. He demonstrated this by quoting the audio chipset specification manual.

So, if you say that my problem of having mute at 14% is caused by the fact that ALSA does not put -inf when the volume is 0%, this will never be possible (with my chipset). If instead the problem is different, please tell me how can I discover which are the wrong dB values exported by ALSA.

I visited this wiki page http://pulseaudio.org/wiki/BadDecibel and executed the application: ./dbverify 0 Master 30 200 I hear the sound all the times with the same amplitude, but I don't understand what exactly should I do. The application output should really be more verbose and tell the user what to do.

[yelo3]

Question from ALSA mailing list:

"since PA provide software atten/software gain ,the software atten of 16bits audio is -48dB

I guess the problem is related to PA shift the 0dB point (i.e. the software gain +15dfB to 0dB)

you have to ask PA developer the value of software dB gain provided by the PA server"

Please answer

[yelo3]

I think I'll close this bug because it is an expected behavior, but I'll open a new one about the 0% = mute