'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/]
