Re: [bug] xmms generating to many wakeups when idle

Dirk Jagdmann <[email protected]> Tue, 14 Aug 2007 20:48:33 +0200
Newsgroups gmane.comp.multimedia.xmms.devel
Organization Cubic
Message-ID <[email protected]>
> I have also tried to take a look at xmms code, and I found out that
> one of the major causes of wakeups is this line in main.c:
> 
> mainwin_timeout_tag = gtk_timeout_add(10, idle_func, NULL);
> 
> If I increase the number 10, I get less wakeups. If I comment the whole
> line the number of wakeups decrease a lot (I get 10 instead of 93).
> 
> However, I don't know the effect of changing this value, because to
> make the vanilla xmms 1.2.10 compile with gcc-4.2.1 I had to change
> some things (I removed two lines from General/ir/ir.h). Xmms then
> compiles fine, but is unable to load and play songs. Modifying the
> source code further to decrease the wakeups, I get the same behaviour
> (does not play).

I'm not surprised. This is the way xmms works, and the only way audio 
apps can be written with OSS like audio driver models. You have to do 
some busy looping, then check your audio driver how much buffer size you 
can render to, then render new audio frames. Only modern audio models 
like ALSA or JACK have a callback interface, where the audio driver (or 
it's library) driver your application. This would allow for better cpu 
usage. If you simply disable xmms busy loop you have halted your player.

But please keep in mind, that generelly multi-media-playback and long 
cpu sleep intervals are sort of mutually exclusive. Because you want 
your media player to have an interface in sync with the output you 
always try to render only short portions of your media. This gives 
shorter processing delay, but increases cpu usage of course.

If you look for an audio player with low cpu footprint, you could try 
"alsaplayer" and make sure you are using ALSA drivers. Generelly you 
want to tune your media player to render as large buffers as possible at 
once.

-- 
---> Dirk Jagdmann ^ doj / cubic
----> http://cubic.org/~doj
-----> http://llg.cubic.org