Version: unspecified (using KDE 4.6.0)
Using the mousewheel on kmix‘s tray icon you can adjust volume in 5% steps, fine.
But I always wondered why I have 34%, 39%, 44% etc till I found out, the first step is 4%. So you decrease volume to zero and increase it by one tick on your mousewheel, it goes to 4%. Make it go just in 5% steps.
*** Bug 266176 has been marked as a duplicate of this bug. ***
Looks like a rounding issue in kmixdockwidget.cpp
val = (vol.getAvgVolume(Volume::MMAIN)*100 )/( vol.maxVolume() );
It always rounds down.
Should be trivial to fix. I don't have much time but if anyone feels like it, then please go ahead.
But when going up to 100% and then going down it‘s normal 95, 90, 85, etc till you are at zero and then back up 4%, 9%, 14%, so you can achieve 5% and 10% but only when going to 100 and then going down
No. That depends on how many steps the specific control has.
e.g. my Master goes for me 100%, 95%, 90%, 85%, 81%, 76%, 71%, 67%, ...
This will always happen, unless 5 is a divisor for the number of steps that a control has, which is nearly never the case (e.g. 4, 8, 16, 32, 256, 32768 possible volume levels are quite common).
Hm, can‘t you make the process “vice-versa” so you have the 5% set in kmix and calculate this for the device instead of calculating down the value the device gives to you?
I just noticed when I increase volume with KMix then I have values like 39% and 44% and 49%. Veromix (a pulseaudio volume plasmoid - which makes KMix superfluid anyway) displays the values KMix sets properly as 45% and 50%
Created attachment 61765 [details]
KMix volume step patch
I found something in kmix sources: int inc = vol.maxVolume () / 20;
I don't like it :). So I wrote a small patch that changes volume change step from 5% to 1% (/20 -> /100) for tray icon (mouse wheel), keyboard shortcuts and kmix window. I hope this is useful to someone and sorry for my English.
Karol, your patch is not required any longer. Volume steps in KMix are configurable starting with KDE4.8:
Also I did some more volume step calculations in https://bugs.kde.org/show_bug.cgi?id=249508 and just now. The calculations are a bit more exact, as a do a bit less rounding. It's nicer now, you often get 5% as first step when you started from 0%.
Backends that use controls in the range 0-100 work perfectly now.
I won't do more, especially not the proposed “vice-versa” thing. Rationale: If a specific control does not support precise x% steps (and there a lot of it), I simply cannot follow the x% steps. Well, I could start "lying" and show a fake value, but I won't do this.
Closing this bug report.
It is not obvious whether this should be closed with FIXED or WONTFIX. But as the original description talked about "First volume step is 4%", I'll tend to FIXED (as the first step is 5% if supported by the Control).
SVN commit 1254102 by esken:
Some more on average calculation (more usage of float instead of long).
M +1 -1 core/mixdevicecomposite.cpp
M +11 -19 core/volume.cpp
M +2 -2 core/volume.h
M +3 -1 dbus/dbuscontrolwrapper.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=1254102