Bug 266175 - First volume step is 4% and then it goes up in 5% steps
Summary: First volume step is 4% and then it goes up in 5% steps
Alias: None
Product: kmix
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR minor
Target Milestone: ---
Assignee: Christian Esken
: 266176 (view as bug list)
Depends on:
Reported: 2011-02-13 01:12 UTC by Kai Uwe Broulik
Modified: 2011-09-17 18:11 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:

KMix volume step patch (3.36 KB, patch)
2011-07-10 18:00 UTC, Karol Grudziński

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Uwe Broulik 2011-02-13 01:12:18 UTC
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
Comment 1 Kai Uwe Broulik 2011-02-13 01:13:15 UTC
*** Bug 266176 has been marked as a duplicate of this bug. ***
Comment 2 Christian Esken 2011-02-13 03:18:09 UTC
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.
Comment 3 Kai Uwe Broulik 2011-02-13 03:20:11 UTC
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
Comment 4 Christian Esken 2011-02-13 03:36:58 UTC
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).
Comment 5 Kai Uwe Broulik 2011-02-13 03:40:24 UTC
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?
Comment 6 Kai Uwe Broulik 2011-07-02 14:10:18 UTC
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%
Comment 7 Karol Grudziński 2011-07-10 18:00:36 UTC
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.
Comment 8 Christian Esken 2011-09-09 20:35:31 UTC
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).
Comment 9 Christian Esken 2011-09-17 18:11:37 UTC
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