summaryrefslogtreecommitdiffstats
path: root/man/pacat.1.xml.in
diff options
context:
space:
mode:
authorColin Guthrie <colin@mageia.org>2011-05-08 12:44:50 +0100
committerColin Guthrie <colin@mageia.org>2011-06-22 22:45:27 +0100
commit1e7c4dd3e6af5bb91bf5e9985725396ebd06293f (patch)
treed85926f1e9f78fd3e7f5791191a0681d0c0fd62e /man/pacat.1.xml.in
parent8203402b9f28da14d03a7120d434f6da7d23f9e6 (diff)
alsa-mixer: When setting hw volume, always round up with playback and down with capture.
The previous logic in ade0a6f88464d8aecf83982d400ccfc402341920 does not work with for input volumes. This was discussed on the mailing list: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2011-May/010091.html This approach can introduce a problem when setting the volumes for sources. What follows is Tanu Kaskinen's analysis: [quote] 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. [/quote] The commit after this contains a patch that addresses this issue.
Diffstat (limited to 'man/pacat.1.xml.in')
0 files changed, 0 insertions, 0 deletions