Bug 235165 - Paused Amarok has high 'powertop' rating
Summary: Paused Amarok has high 'powertop' rating
Status: RESOLVED UPSTREAM
Alias: None
Product: amarok
Classification: Applications
Component: general (show other bugs)
Version: 2.3.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-23 12:52 UTC by Dan
Modified: 2010-08-24 23:43 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan 2010-04-23 12:52:54 UTC
Version:           2.3.0 (using KDE 4.4.1)
OS:                Linux
Installed from:    Ubuntu Packages

Hello,

Powertop is an application that monitors the number of times a given application wakes up the system, causing it to leave low-power mode. This is a particular concern for laptops and netbooks, but is interesting to all systems in general.

Amarok, when stopped (literal 'stop' state), doesn't rate at all as a significant cause of interrupts. However, Amarok when PAUSED rates very highly. This means that Amarok, when paused, is costing systems a lot of power.

Amarok deprecated the stop button in favor of the pause button (which, by the way, was a great UI decision). However, as a result, there is no easy way to cause Amarok to stop heavily waking the CPU. Furthermore, there is no good reason why a paused Amarok should interrupt the CPU any more than the stopped Amarok should (hence the bug).

So, in summary, the bug is that Amarok, when paused, has a high (the highest in my system) 'powertop' rating, and should, in fact, have little-to-no 'powertop' rating in this state.
Comment 1 Sven Krohlas 2010-04-23 13:03:17 UTC
I suppose you understand that this report is waaaay to general to start working on the problem.

1. Test with 1.3.1 beta 1 , please
2. Try to find out which parts of Amarok cause those wakeups. The Phonon engine maybe? Try GStreamer instead of Xine, retest. An applet? Try removing the applets, retest. MySQL embedded? Try the server support.

Maybe the problem lies in combinations of those: in that case file bugs for every component that causes unnecessary wakeups.
Comment 2 Sven Krohlas 2010-04-23 13:06:57 UTC
I wanted you to test with 2.3.1 beta 1, of course. Stupid typo. ;-)
Comment 3 Dan 2010-04-24 15:52:17 UTC
Quote sorry for the inadequate information. Let me make that up to you:

I have just checked out the latest build of Amarok from 'git', built it, and removed every widget and pane save "Media Sources" and "Playlist". I have also disabled every script. The build of Amarok is "2.3-GIT" running on KDE "4.4.2" (which was built by Kubuntu package maintainers). Unfortunately, when I tried to switch to Gstreamer Phonon backend, I encountered a crashing issue.

Here are my readings from 'powertop':
Just Started Up (Idle): 0.6% (  3.4) amarok : hrtimer_start_range_ns (hrtimer_wakeup)
Playing a Song: 16.1% (114.4) amarok : hrtimer_start_range_ns (hrtimer_wakeup) 
Paused: 20.1% (150.7) amarok : hrtimer_start_range_ns (hrtimer_wakeup)
Stopped:  2.3% ( 15.4) amarok : hrtimer_start_range_ns (hrtimer_wakeup) 

It seems that the bug is still present for me even in these circumstances. I hope this information is more helpful!
Comment 4 Dima Ryazanov 2010-04-30 09:49:55 UTC
I noticed the high number of wakeups, too. I'm using Amarok 2.3.0.

I ran "strace -f -p [...]", and saw tons of calls like these:

[pid  1566] select(0, NULL, NULL, NULL, {0, 10000} <unfinished ...>
[pid  4214] <... select resumed> )      = 0 (Timeout)
[pid  4214] select(0, NULL, NULL, NULL, {0, 20000} <unfinished ...>
[pid  1566] <... select resumed> )      = 0 (Timeout)
[pid  1566] select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
[pid  1566] select(0, NULL, NULL, NULL, {0, 10000} <unfinished ...>
[pid  4214] <... select resumed> )      = 0 (Timeout)
[pid  4214] select(0, NULL, NULL, NULL, {0, 20000} <unfinished ...>
[pid  1566] <... select resumed> )      = 0 (Timeout)

Then I ran GDB and set a breakpoint on "select", and got:

#0  select () at ../sysdeps/unix/syscall-template.S:82
#1  0x00007f5de35562c5 in xine_usec_sleep (usec=<value optimized out>) at utils.c:481
#2  0x00007f5de353afb4 in paused_loop (this_gen=<value optimized out>) at video_out.c:1116
#3  video_out_loop (this_gen=<value optimized out>) at video_out.c:1225
#4  0x00007f5df17b69ca in start_thread (arg=<value optimized out>) at pthread_create.c:300
#5  0x00007f5df336c69d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#6  0x0000000000000000 in ?? ()

I guess Xine is constantly polling something?
Comment 5 Mark Kretschmann 2010-06-01 16:41:51 UTC
This is actually a known problem in xine itself, nothing we could do about, sorry.

Other Phonon backends (like the new VLC backend which is in development) do not have this issue, so it will fix itself once we switch to that new backend.
Comment 6 niburu1 2010-06-26 15:59:30 UTC
I recently noticed this issue as well. At least "stop" is an option.
Comment 7 Nikos Chantziaras 2010-08-24 23:43:33 UTC
Please add a small stop button in the main toolbar. Or make the pause button stop when double-clicking, and pause when single-clicking.

Many people request this, so please consider it.