Bug 213058 - Audacious wakes up ~600 times / second
Summary: Audacious wakes up ~600 times / second
Alias: None
Product: Fedora
Classification: Fedora
Component: audacious
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ralf Ertzinger
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: wakeup
TreeView+ depends on / blocked
Reported: 2006-10-30 18:09 UTC by Henning Norén
Modified: 2008-06-17 01:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-06-17 01:14:23 UTC

Attachments (Terms of Use)

Description Henning Norén 2006-10-30 18:09:53 UTC
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):

How reproducible:

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

$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

Comment 1 Ralf Ertzinger 2006-10-30 20:20:56 UTC
Hmmm, looks like ancient leftovers, xmms does this as well :)
I'll report this to upstream, but don't hold your breath about this.

Comment 2 Henning Norén 2006-10-30 20:57:05 UTC
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

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.

Comment 3 Henning Norén 2006-10-30 22:56:47 UTC
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.

Comment 4 Ralf Ertzinger 2006-10-31 10:11:31 UTC
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.

Comment 5 Ralf Ertzinger 2006-10-31 10:24:34 UTC
I seem to be unable to find the source line you qouted in the audacious 1.1.2
source tarball.

Comment 6 Ralf Ertzinger 2006-10-31 10:54:19 UTC
Nevermind, found it.

Comment 7 Henning Norén 2006-10-31 11:44:34 UTC
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.

Comment 8 Ralf Ertzinger 2006-11-09 17:45:05 UTC
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.

Comment 9 Bug Zapper 2008-05-14 12:04:02 UTC
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:

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bug Zapper 2008-06-17 01:14:22 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.