Bug 204114 - lots of cpu wakeups after playing some mp3s
Summary: lots of cpu wakeups after playing some mp3s
Status: RESOLVED UPSTREAM
Alias: None
Product: Phonon
Classification: Frameworks and Libraries
Component: Xine backend (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Matthias Kretz
URL:
Keywords:
: 210409 212604 214799 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-17 04:31 UTC by LuRan
Modified: 2009-12-19 07:59 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LuRan 2009-08-17 04:31:24 UTC
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.
Comment 1 Edward Hades 2009-08-17 08:04:56 UTC
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.
Comment 2 Mark Kretschmann 2009-08-21 15:07:45 UTC
For reference also see BUG 177517. There was a problem in Phonon that was supposedly fixed a while ago.
Comment 3 Stefan Fleiter 2009-10-09 16:26:19 UTC
This is still happening with KDE 4.3.2 und amarok 2.2 on Ubuntu Karmic 9.10.
Comment 4 Mark Kretschmann 2009-10-09 18:27:11 UTC
 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.
Comment 5 Mark Kretschmann 2009-10-13 10:15:33 UTC
*** Bug 210409 has been marked as a duplicate of this bug. ***
Comment 6 Mark Kretschmann 2009-10-13 15:14:15 UTC
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.
Comment 7 Mark Kretschmann 2009-11-01 12:32:19 UTC
*** Bug 212604 has been marked as a duplicate of this bug. ***
Comment 8 Helio Chissini de Castro 2009-11-08 11:59:34 UTC
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.
Comment 9 Helio Chissini de Castro 2009-11-08 12:13:37 UTC
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
Comment 10 Rex Dieter 2009-11-24 15:43:07 UTC
marking as an upstream bug in xine-lib then.
Comment 11 Mark Kretschmann 2009-11-25 07:35:45 UTC
*** Bug 214799 has been marked as a duplicate of this bug. ***
Comment 12 Hector Martin 2009-12-19 04:01:03 UTC
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.
Comment 13 Myriam Schweingruber 2009-12-19 07:59:07 UTC
Hector, please file a separate bug for the Phonon Xine video loop related part then, this one is closed for the Xine bug.