Re: [As-users] AfterStep using 100% CPU when playing music
Jeff Krebs (jkrebs@tconl.com)
Thu, 2 Aug 2007 08:01:42 -0500
I installed the 2.2.6 RPM from the AfterStep website on FC7.
I logged-in under 2.2.6, started xterm, and ran the script example=20
provided. I ran it for an hour with no appreciable gain in CPU load.
The 2.2.6 RPM does NOT have --with-gdb enabled.
Wmcpuload gave a constant 3% to 5% reading, and was at 3% when I=20
CTRL-C'd the script.
This issue is very odd. I wonder what the culprit is?
I also ran the script under CVS with no issues either.
CVS had --with-gdb enabled.
Jeff Krebs
* Volker Ossenkopf (ossk@ph1.uni-koeln.de) wrote:
> Dear all,
>=20
> > The bulk of my played music is MP3 or WAV. Is there a particular forma=
t=20
> > that seems to be affected more than others? Does this happen with =20
> > AfterStep and no other applications open? Is this playing from a list?=
=20
> > Or are you loading the tunes one at a time?
>=20
> I didn't do any debugging, but I noticed that the problem was the same
> or even worse on my system (Debian etch with afterstep 2.2.6) while
> opening a particular website that updated the window title every
> second.
>=20
> This gives an easy way of testing the problem completely independent
> from xmms:
> I ran xterm and within the xterm-bash the loop:
> ossk@hevelius: while (true); do echo -n "^[]0;`date`^G"; sleep 1; done
> (^[ is the character for escape and ^G the character for bell)
> This updates the xterm window every second. In this way one can easily
> time the problem:
> After about 8 minutes I notice the first increase in the afterstep
> load (6%), after 16 minutes, I am at about 20%, after 24 minutes
> I am at 30%, after 32 minutes 45%.
> The load drops immediately to zero when I stop the loop in the xterm,
> so that the title is no longer updated.
>=20
> The delayed behaviour seems to indicate a memory management problem
> for the structure containing the window titles. This might explain,
> why the problem does not seem to occur on all systems using afterstep,
> but may depend on an underlying library.
>=20
> I don't want to make further guessing about the cause here, but hope
> that this gives at least some additional information.
>=20
> Cheers
> Volker
> --=20
> ----------------------------------------------------------------------
> Volker Ossenkopf ossk@ph1.uni-koeln.de
> Space Research Organization Netherlands - Groningen +31 50 3634799
> 1. Physikalisches Institut der Universit=E4t zu K=F6ln +49 221 4703485
> ----------------------------------------------------------------------
_______________________________________________
As-users mailing list
As-users@afterstep.org
http://mail.afterstep.org/mailman/listinfo/as-users