Version: unspecified (using KDE 4.6.0) OS: Linux 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. Reproducible: Always
*** 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: http://kmix5.wordpress.com/2011/08/10/what-is-hot-for-kde-4-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: CCBUGS: 266175 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