'Twas brillig, and Colin Guthrie at 17/05/11 12:13 did gyre and gimble: > '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).
Just to report that a modified version of that patch does indeed fix the problem for me. What do you think overall? Should we try and hunt down the problems with the conversion or should this patch be included? 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/] _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
