Andrew Suffield wrote: > Are you trolling, No. Somebody told xine performs better, and I provided benchmarks. And you didn't believe them. > or do you just have no understanding of how scheduling works and what the > CPU% value means? After two years in media players, I thought I know what I am talking about. > ..[cut blabla].. Yes, top can be very unreliable, especially when usleep()s are in use. However just try to play a simple MP3 with aaxine: Cpu(s): 44.5% user, 55.5% system, 0.0% nice, 0.0% idle, 0.0% IO-wait And with MPlayer: Cpu(s): 1.0% user, 3.6% system, 0.0% nice, 95.4% idle, 0.0% IO-wait But I also just did a more "real-life" benchmark: time gcc ... postprocess.c -o postprocess.o . It takes 13.821s if no other process is running. Then I started MP3 playing for each software, and compiled. The results are as follows: aaxine: 36.842s mplayer: 15.971s So with MPlayer running, compilation took 2.1 seconds more. With xine running, compilation took 23.021 seconds more. (yes, the compilation was always cached to memory.) So thanks for your mail, but next time you doubt I can read 'top' output, think twice. <sigh> -- Gabucino MPlayer Core Team
Attachment:
pgp9fyNOTypTf.pgp
Description: PGP signature