Version: git snapshot (using Devel) Compiler: gcc 4.4.1 with gentoo patches OS: Linux Installed from: Compiled sources When Amarok is just started, the wakeups shown in powertop is 5 times per second, then when I play a random mp3 the wakeups goes up to approximately 100, which is ok I presume. But the strange thing is, the wakeups never drop, even after the mp3 is finished. It stays around 1xx times per second until Amarok is killed.
Indeed that happens. My suspicion is that it's not Amarok who is causing the wakeups, but the underlying sound backend. I'll dig into it, thanks for the report.
For reference also see BUG 177517. There was a problem in Phonon that was supposedly fixed a while ago.
This is still happening with KDE 4.3.2 und amarok 2.2 on Ubuntu Karmic 9.10.
17.4% (102.8) amarok : hrtimer_start_range_ns (hrtimer_wakeup) This is with latest 2.2-GIT, in stopped state. So you've got a point. But I have no idea what's causing it. I did at one point check all our timers, there wasn't anything running with high frequency.
*** Bug 210409 has been marked as a duplicate of this bug. ***
Ok, as it turns out, this is probably an issue with the Phonon-xine backend. I've just talked this over with the Phonon maintainer. Reassigning the report.
*** Bug 212604 has been marked as a duplicate of this bug. ***
Current svn trunk with amarok 2.2.1 is keeping stable in 10 wakeups, receiving a peek of 20-30 wakeups in a nes start, but decreasing to around 10 again. Closing as works for me. 2 different distros.
Compared phonon backends, the behavior is erratic for xine backend, which lead a mistaken to assign bug phonon itself. The issue is in xine libraries. Usage of any app outputting to xine, even standard xine ui generates wakeup peaks sometimes higher than generated by phonon. Regular usage in xine-ui. Never decrease, same behavior as described in bug 11,8% (192,1) xine : hrtimer_start_range_ns (hrtimer_wakeup) So the bug is elsewhere and i ḿ closing as wontfix. Thanks in advance
marking as an upstream bug in xine-lib then.
*** Bug 214799 has been marked as a duplicate of this bug. ***
There are three problems here. One is a Phonon issue, one is a Xine issue, and one I'm not sure. 1) Phonon keeps the Xine backend stuff running after hitting stop (the video thread keeps running). This affects both Amarok and e.g. previewing an MP3 in Dolphin. I'm pretty sure this can be fixed in Phonon. In fact, I believe this issue already happened with knotify and was subsequently fixed or worked around. Xine's processing loops need to be shut down when not playing music. 2) Xine's video thread is running even when playing just audio. I have no clue if this is simply mandatory or if it can be fixed at the Phonon end. 3) Xine's video thread loops around in 1ms timeouts (which get rounded to 10ms). This is in video_out_loop inside video_out.c in xine-lib. There's no video, so it "doesn't know" what timeout to use and defaults to a tight 1ms loop (the underlying function pushes this up to 10ms, but it's still bad). Look for xine_usec_sleep. I patched Xine to report the offending xine_usec_sleep calls and all are caused by the useless video loop. This isn's just some spurious problem in the audio part; the big question is why on earth is the video loop running at all.
Hector, please file a separate bug for the Phonon Xine video loop related part then, this one is closed for the Xine bug.