[pulseaudio-discuss] [PATCH] alsa-mixer: When setting hw volume, round always up with playback and always down with capture.
gmane at colin.guthr.ie
Tue May 17 04:13:02 PDT 2011
'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:
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).
Tribalogic Limited [http://www.tribalogic.net/]
Mageia Contributor [http://www.mageia.org/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
More information about the pulseaudio-discuss