Bug 206051

Summary: [patch] kmix consumes too much CPU while idle
Product: [Applications] kmix Reporter: Nick Hibma <nick>
Component: generalAssignee: Christian Esken <esken>
Status: RESOLVED FIXED    
Severity: wishlist CC: avilla, finex, vasilis.tsolis, zanetu
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: FreeBSD   
Latest Commit: Version Fixed In:

Description Nick Hibma 2009-09-02 22:50:16 UTC
Version:            (using KDE 4.3.0)
OS:                FreeBSD
Installed from:    Unspecified BSD

While laptop is idle, kmix consumes more CPU than korgac (after increasing the polling interval on korgac).

kmix lacks this feature. It polls the /dev/mixer device on FreeBSD every 50ms. The only useful effect of this high frequency is that the slider moves with the new setting when setting the volume in another app.

I would like to suggest increasing the polling interval to 200ms or more (I personally have set it to 1000ms.

--- mixer_backend.cpp~  2009-09-02 22:38:02.000000000 +0200
+++ mixer_backend.cpp   2009-09-02 22:38:24.000000000 +0200
@@ -51,7 +51,7 @@
         // but we want a somehow usable fallback just in case.
     
         if ( needsPolling() ) {
-            _pollingTimer->start(50);
+            _pollingTimer->start(1000);
         }
         else {
             // The initial state must be read manually
Comment 1 FiNeX 2009-09-03 16:25:00 UTC
I've tried with 250ms. Kmix now uses about 6Mb instead of 12Mb of memory and the sliders are immediatly updated when other apps modify the volume levels.

I think 250ms could be a good compromise. Increasing the value didn't free more memory.
Comment 2 FiNeX 2009-09-03 16:25:37 UTC
Maybe you could commit the patch to the reviewboard.
Comment 3 Vasilis 2010-11-12 18:57:15 UTC
Just to second this bug. Kmix seemed to be 600mb!
Comment 4 Christian Esken 2011-08-09 20:48:10 UTC
KMix has adaptive polling now.
KMix polls  with 500ms normally. When changes were detected, it uses 50ms for 5 seconds. After that KMix reverts back to 500ms.
Comment 5 Christian Esken 2011-08-09 20:52:36 UTC
SVN commit 1246048 by esken:

FEATURE: 206051
Save battery power and CPU cycles by adaptive polling (500ms normally. And 50ms during changes). 

 U             mixer_backend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1246048
Comment 6 Christian Esken 2011-08-19 19:15:39 UTC
SVN commit 1248123 by esken:

CCBUGS: 206051
Be extra defensive: Don't accidently start timer when polling not required.

 M  +2 -0      mixer_backend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1248123
Comment 7 Christian Esken 2011-08-19 19:48:37 UTC
SVN commit 1248126 by esken:

CCBUGS: 206051
Be extra defensive: Don't accidently start timer when polling not required.

 M  +2 -0      backends/mixer_backend.cpp  
 M  +1 -1      core/mixer.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1248126
Comment 8 Christian Esken 2011-08-27 11:58:06 UTC
I did some extra research with the "powertop" utility, using 4 installed soundcards:
Before the path KMix was responsible for 10-20% of all wakeups.
After the path KMix was responsible for 0.7 - 3% of all wakeups.

I consider this is still too much, even though it would be 1/4 of the measured values for users with only 1 soundcards. I changed the slow-polling from 500ms to 1500ms, which leads to a mesured 0.1% wakeup rate (0,6 wakeups per second). I'll commit this change soon.

For the records: Using the ALSA backend, KMix isn't even shown in the "powetop" list, and "top" lists KMix at the very bottom - which means it uses least of all the user processes.
Comment 9 Christian Esken 2011-08-27 12:01:35 UTC
SVN commit 1249692 by esken:

CCBUGS: 206051
Change polling rate from 500ms to 1500ms. This leads to an acceptable
measured (powetpop) wakeup rate of 0,6 wakeups per second for those backends
that require polling.


 M  +8 -4      mixer_backend.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1249692