Lee Revell wrote:
I'm not sure. Probably depends on how long you usleep() or the
interrupt frequency of
On Fri, 2004-09-17 at 12:32, Thomas Hellström wrote:
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.
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
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.