Lee Revell wrote:
On Fri, 2004-09-17 at 12:32, Thomas Hellström wrote:
Hi, Ivor!

With xine it's around 12% with AGP enabled, around 30% without AGP.
About 6% of those is audio (M10K)
If you put a usleep(1) after every second putslice() or putslice2(),
"Unichrome cpu-saving mode" corresponding figures are 7-8% and 12%,
still 6% of those is audio. But I believe mplayer uses RTC to sync 
frame, whereas xine just usleeps. RTC is more costly.


Try mplayer -nortc.  mplayer also falls back to usleep() if the RTC is

Why is the RTC more costly than usleep()?  Seems like it would be
cheaper.  The mplayer docs say that usleep() timing consumes more CPU.
I'm not sure. Probably depends on how long you usleep() or the interrupt frequency of

Previously I used RTC to poll the mpeg decoder for completion, since I needed a polling frequency of at least 4kHz to keep up with the decoder. I did a comparison with 1kHz polling frequency and compared that to usleep(1), which sleeps a millisec on 2.6. With the latter, video decoding with "mp2player" was down at less than  1% CPU!!, With RTC I had 6-8%, regardless, it seemed, of the polling freqency. I never figured out why. I thought it was due to costly asynchronous context switches.
When I made a minimal program that just polled with RTC at 1kHZ, did hardly consume any CPU at all.

At that time I saw the UFO outside the window and it all became clear. ;-)