Summary: | First volume step is 4% and then it goes up in 5% steps | ||
---|---|---|---|
Product: | [Applications] kmix | Reporter: | Kai Uwe Broulik <KaiUweBroulik2> |
Component: | general | Assignee: | Christian Esken <esken> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | sreejiththulaseedharan |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | KMix volume step patch |
Description
Kai Uwe Broulik
2011-02-13 01:12:18 UTC
*** 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 |