SUMMARY I've just updated to Plasma 5.21.3 (Fedora 34 KDE Beta) and every time I adjust volume which is set to adjust at 5% increment/decrement, at some point (twice to be precise) it goes to more than 5% (6%). STEPS TO REPRODUCE 1. Try to adjust volume with either a mouse and a taskbar audio icon or with a keyboard volume dial OBSERVED RESULT The whole scale looks like: 0-5-10-15-20-25-30-*36*-41-46-51-56-61-66-71-76-81-*87*-92-97-100 and backwards: 100-95-90-85-80-75-70-*64*-59-54-49-44-39-34-29-24-19-*13*-8-3-0 EXPECTED RESULT Whole scale goes at 5% change SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 34 Beta KDE Spin (available in About System) KDE Plasma Version: 5.21.3 KDE Frameworks Version: 5.80 Qt Version: 5.15.2 ADDITIONAL INFORMATION
Can confirm. Bugs me too.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-pa/-/merge_requests/55
Git commit 52cb6b0eecc3092708c207346a13a36e772a6bca by Nate Graham. Committed on 22/03/2021 at 18:07. Pushed by ngraham into branch 'master'. Round volume to avoid increasing or decreasing by more than stepSize Sometimes when you increase or decrease the volume using the key on your keyboard or a global shortcut, it will change by more than the stepSize. For example when you're at 40% volume and go up when a stepSize of 5%, sometimes it will change to 46% volume, not 45%. The reason for this is that the Volume number we get from PulseAudio and then manipulate is a float. So we have to round it down to avoid accumulating errors over time. The percentage display function already rounds, so let's do the same thing in the functions to increase and decrease the volume. We should also use Math.floor() rather than Math.round() to ensure consistency in the values we're using. FIXED-IN: 5.21.4 M +2 -2 applet/contents/ui/main.qml https://invent.kde.org/plasma/plasma-pa/commit/52cb6b0eecc3092708c207346a13a36e772a6bca
Git commit b0f7cfccf80d00d9e76efa05d02bc2fc94b4318d by Nate Graham. Committed on 27/03/2021 at 03:26. Pushed by ngraham into branch 'Plasma/5.21'. Round volume to avoid increasing or decreasing by more than stepSize Sometimes when you increase or decrease the volume using the key on your keyboard or a global shortcut, it will change by more than the stepSize. For example when you're at 40% volume and go up when a stepSize of 5%, sometimes it will change to 46% volume, not 45%. The reason for this is that the Volume number we get from PulseAudio and then manipulate is a float. So we have to round it down to avoid accumulating errors over time. The percentage display function already rounds, so let's do the same thing in the functions to increase and decrease the volume. We should also use Math.floor() rather than Math.round() to ensure consistency in the values we're using. FIXED-IN: 5.21.4 (cherry picked from commit 52cb6b0eecc3092708c207346a13a36e772a6bca) M +2 -2 applet/contents/ui/main.qml https://invent.kde.org/plasma/plasma-pa/commit/b0f7cfccf80d00d9e76efa05d02bc2fc94b4318d
Hm, I'm using now Plasma 5.21.4 and increasing volume seems to work fine, but the very first decrease from 100 goes to 94. The rest of the scale goes at -5%, seems like some corner case is missing.
Yeah, we are working on a better fix: https://invent.kde.org/plasma/plasma-pa/-/merge_requests/57
*** Bug 435571 has been marked as a duplicate of this bug. ***
Git commit dedcbccf753545795c0194fd98cca081e47baf70 by Chris Holland. Committed on 20/04/2021 at 02:56. Pushed by ngraham into branch 'master'. Increment volume by percent instead of a constant volumeStep Jumping by a fixed volumeStep has issues as the value is rounded. 65536/100 = 655.36 65536/100*5 = 3276.8 volumeStep = round(3276.8) = 3277 The floor() patch has an easy to test bug when jumping from 100% to 94% instead of 95% since volumeStep is rounded up. Eg: 65536 => 62259 (-3277) 100% => 94% (-6%) The original round() logic also has issues when volume is around: f(x) = (65536/100) / 2 + (65536/100) * x amixer sset Master 983 # f(1)=983.04 Eg: 983 => 4260 (+3277) 1% => 7% (+6%) This patch adds changeVolumeByPercent(volumeObject, deltaPercent) to increment any sink or source by a %volume. It also moves the common code in increaseVolume() and decreaseVolume() into a new function. Related: bug 435522 FIXED-IN: 5.21.5 M +33 -32 applet/contents/ui/main.qml https://invent.kde.org/plasma/plasma-pa/commit/dedcbccf753545795c0194fd98cca081e47baf70
Git commit 26994d67552d21ce41f641de473be2b7b3509834 by Nate Graham, on behalf of Chris Holland. Committed on 20/04/2021 at 15:42. Pushed by ngraham into branch 'Plasma/5.21'. Increment volume by percent instead of a constant volumeStep Jumping by a fixed volumeStep has issues as the value is rounded. 65536/100 = 655.36 65536/100*5 = 3276.8 volumeStep = round(3276.8) = 3277 The floor() patch has an easy to test bug when jumping from 100% to 94% instead of 95% since volumeStep is rounded up. Eg: 65536 => 62259 (-3277) 100% => 94% (-6%) The original round() logic also has issues when volume is around: f(x) = (65536/100) / 2 + (65536/100) * x amixer sset Master 983 # f(1)=983.04 Eg: 983 => 4260 (+3277) 1% => 7% (+6%) This patch adds changeVolumeByPercent(volumeObject, deltaPercent) to increment any sink or source by a %volume. It also moves the common code in increaseVolume() and decreaseVolume() into a new function. Related: bug 435522 FIXED-IN: 5.21.5 (cherry picked from commit dedcbccf753545795c0194fd98cca081e47baf70) M +33 -32 applet/contents/ui/main.qml https://invent.kde.org/plasma/plasma-pa/commit/26994d67552d21ce41f641de473be2b7b3509834
*** Bug 436138 has been marked as a duplicate of this bug. ***