Bug 213058 - Audacious wakes up ~600 times / second
Audacious wakes up ~600 times / second
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: audacious (Show other bugs)
7
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ralf Ertzinger
Fedora Extras Quality Assurance
:
Depends On:
Blocks: wakeup
  Show dependency treegraph
 
Reported: 2006-10-30 13:09 EST by Henning Norén
Modified: 2008-06-16 21:14 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 21:14:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Henning Norén 2006-10-30 13:09:53 EST
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
Comment 1 Ralf Ertzinger 2006-10-30 15:20:56 EST
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 15:57:05 EST
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.
Comment 3 Henning Norén 2006-10-30 17:56:47 EST
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 05:11:31 EST
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 05:24:34 EST
Errr...
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 05:54:19 EST
Nevermind, found it.
Comment 7 Henning Norén 2006-10-31 06:44:34 EST
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 12:45:05 EST
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 08:04:02 EDT
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
Comment 10 Bug Zapper 2008-06-16 21:14:22 EDT
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.