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

[Colin Guthrie]

'Twas brillig, and Tanu Kaskinen at 17/05/11 10:37 did gyre and gimble:
> 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

Thanks, I'll test this patch and see if it helps with my test case.

Assuming that it does, is this something we should really push to alsa
lib? When I first encountered the problem I did start hacking away at
alsa lib looking for the problem.

Perhaps a new direction argument -2 and +2 for "nearest below bias" and
"nearest above bias" respectively? (the bias only coming into play when
there you are exactly inbetween two possible values).

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]