Description of problem: Audacious is waking up alot just by being open, without having anything in playlist or playing. Version-Release number of selected component (if applicable): audacious-1.1.2-2.fc6 How reproducible: Always Steps to Reproduce: 1. strace -c -p <Audacious-PID> 2. Ctrl-C after 10 seconds and observe the numbers Actual results: strace -c -p <Audacious-PID> Process <Audacious-PID> attached - interrupt to quit Process <Audacious-PID> detached % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- nan 0.000000 0 6 read nan 0.000000 0 435 write nan 0.000000 0 77 open nan 0.000000 0 77 close nan 0.000000 0 1135 ioctl nan 0.000000 0 1960 gettimeofday nan 0.000000 0 984 poll nan 0.000000 0 1278 clock_gettime ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000000 5952 total Expected results: Zero or very few syscalls when not doing anything Additional info: $rpm -qa | grep audacious audacious-debuginfo-1.1.2-2.fc6 audacious-1.1.2-2.fc6 $uname -a Linux ******* 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:37:32 EDT 2006 i686 athlon i386 GNU/Linux Excerpt from strace: gettimeofday({1162231578, 526704}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {9516, 577184625}) = 0 clock_gettime(CLOCK_MONOTONIC, {9516, 577237214}) = 0 write(3, "\222\3\n\0\3\0@\4;\0@\4\0\6@\0\240\4 \0L\0\20\0\30\0+\0"..., 40) = 40 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1162231578, 528871}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}], 6, 7) = 0 gettimeofday({1162231578, 535474}, NULL) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1162231578, 535594}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}], 6, 1) = 0 gettimeofday({1162231578, 539089}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {9516, 587852940}) = 0 ioctl(3, FIONREAD, [0]) = 0 gettimeofday({1162231578, 539328}, NULL) = 0 poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=9, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}], 6, 9) = 0 gettimeofday({1162231578, 554975}, NULL) = 0 clock_gettime(CLOCK_MONOTONIC, {9516, 603834068}) = 0 clock_gettime(CLOCK_MONOTONIC, {9516, 603957954}) = 0 write(3, "\222\3\n\0\3\0@\4;\0@\4\0\6@\0\0\0040\0L\0\20\0\30\0+\0"..., 40) = 40
Hmmm, looks like ancient leftovers, xmms does this as well :) I'll report this to upstream, but don't hold your breath about this.
Well, I got the title wrong... It's 600 syscalls / second, not wakeups (they are probably around 100/second) from the numbers above. And I noticed that turning off visualization-plugin and autoscrolling made the numbers a bit more sensible (at least removes the open/close/write and the clock_gettime). I did contact upstream but after being insulted and practically ignored by some of the developers I hardly think they will get down from their high horses and do anything about it. I'll see if I can take a look into it as soon as I get some time though... The issue is probably a timeout that needs to be set higher and using interrupt on the polling thread instead of constantly checking a variable.
Ok, this one will be tricky... I found the offending code and from a quick look it will demand some rewrite to fix. The offending line is the following in main.c (in both xmms and Audacious): mainwin_timeout_tag = gtk_timeout_add(10, idle_func, NULL); Bluntly removing it makes the repainting of graphics highly defective but the player is still working and a strace shows that the continous polling when idle is gone.
A quite simple fix would be to increase the first parameter from 10 to 100, and cutting the number of calls down by 10. And gtk_add_timeout is deprecated anyway, and should be replaced by g_timeout_add. I'll take a look at what that idle function is doing, anyway.
Errr... I seem to be unable to find the source line you qouted in the audacious 1.1.2 source tarball.
Nevermind, found it.
sorry, it was in xmms... They have changed the code a bit but the new line is; mainwin.c:3362 mainwin_timeout_id = g_timeout_add(MAINWIN_UPDATE_INTERVAL, mainwin_idle_func, NULL); Where MAINWIN_UPDATE_INTERVAL is defined as 10, so it's pretty much the same.
Testing a patch in devel shows that simply reducing this variable has unwanted side effects. So currently I see no simple way around this. If you are willing to work further on this you're welcome, of course.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.