[pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.

[Tanu Kaskinen]

On Mon, 2011-05-16 at 21:22 +0100, Colin Guthrie wrote:
> OK, here is the debug output from my run using this volume approach....
> 
> As you can see there are several points where the message:
> 
> "Written HW volume did not match with the request" is shown. This is
> shown quite clearly when writing the volumes to h/w
> 
> I suspect this problem arrises due to the use of pa_cvolume_divide()
> which is based around PA_VOLUME_NORM, when the second argument (the
> software volume) is > PA_VOLUME_NORM.
> 
> Any thoughts on this are welcome.

I'll quote the log:

D: protocol-native.c: Client pavucontrol changes volume of source alsa_input.pci-0000_00_1b.0.analog-stereo.
D: alsa-source.c: Requested volume: 0:  45% 1:  45%
D: alsa-source.c:            in dB: 0: -20.71 dB 1: -20.71 dB
D: alsa-source.c: Got hardware volume: 0:  45% 1:  45%
D: alsa-source.c:               in dB: 0: -21.00 dB 1: -21.00 dB
D: alsa-source.c: Calculated software volume: 0: 101% 1: 101% (accurate-enough=no)
D: alsa-source.c:                      in dB: 0: 0.29 dB 1: 0.29 dB
D: source.c: Volume going up to 29273 at 270475970821
D: source.c: Volume change to 29273 at 270475970821 was written 34 usec late
D: alsa-source.c: Written HW volume did not match with the request: 0:  45% 1:  45% (request) != 0:  42% 1:  42%
D: alsa-source.c:                                            in dB: 0: -21.00 dB 1: -21.00 dB (request) != 0: -22.50 dB 1: -22.50 dB

Looking at the last line, the requested volume seems to hit exactly the
right step (-21.00dB), but for some reason Alsa decides to choose
something else. I'm pretty sure that this happens because of rounding
errors. In the first phase we ask Alsa what dB value we should set, and
it returns -21.00 dB. The value is given as a long int, but we convert
that to pa_cvolume. Then when we set the volume, we convert the
pa_cvolume value back to a long integer. At this point I believe it gets
converted to -2101. This is not visible in the debug message for some
reason - the rounding algorithm must be different from what was used
with the pa_cvolume -> long conversion.

Here's a patch that should fix the problem:

http://meego.gitorious.org/maemo-multimedia/pulseaudio/commit/a88c2b1d9f8c2088a430a257470a70efeaaf4b34

-- 
Tanu