On Sun, 14 May 2000, Rob Leslie wrote:
Your binaries are probably fine, but do you want me to send you a `time' program? (If so, please follow up privately.) You could try timing the pure decoding time like I did by dumping the PCM output to /dev/null.
OK, so I just did on SA1100 hardware for which I don't currently have audio output support:
[root@thinclient /]# date; splay -d - test.mp3 | cat > /dev/null; date Mon May 15 21:43:44 EDT 2000 Mon May 15 21:44:11 EDT 2000
[root@thinclient /]# date; madplay -o raw:/dev/null test.mp3; date Mon May 15 21:50:42 EDT 2000 MPEG Audio Decoder version 0.10.3 (beta) - Copyright (C) 2000 Robert Leslie test.mp3: 1959 frames decoded (0:51.1) Mon May 15 21:51:02 EDT 2000
[root@thinclient /]# cat /proc/cpuinfo Processor : Intel StrongARM-1100 rev 9 (v4l) BogoMIPS : 124.52 Hardware : ADS ThinClient
[root@thinclient /dev]# uname -s -r Linux 2.3.99-pre8-rmk1-np1
So we got:
splay: 27 sec 52.8 %CPU if real-time madplay: 20 sec 39.1 %CPU if real-time
The same tests with the same binaries on SA1110 hardware gave me:
[root@Linux /]$date; splay -d - test.mp3 | cat > /dev/null; date Thu Jan 1 00:17:03 UTC 1970 Thu Jan 1 00:17:27 UTC 1970
[root@Linux /]$date; madplay -o raw:/dev/null test.mp3; date Thu Jan 1 00:22:16 UTC 1970 MPEG Audio Decoder version 0.10.3 (beta) - Copyright (C) 2000 Robert Leslie test.mp3: 1959 frames decoded (0:51.1) Thu Jan 1 00:22:27 UTC 1970
[root@Linux /]$cat /proc/cpuinfo Processor : Intel StrongARM-1110 rev 5 (v4l) BogoMIPS : 194.15 Hardware : Intel-Assabet
[root@Linux /]$uname -s -r Linux 2.3.99-pre8-rmk1-np1
So we get:
splay: 24 sec 47.0 %CPU if real-time madplay: 11 sec 21.5 %CPU if real-time
So by looking at this splay is much worse than madplay... and even more on a SA1110 which is pretty weird.
However, here is what 'time' produces when both players are actually playing:
[root@Linux /]$time splay test.mp3 8.81user 0.25system 0:50.44elapsed 17%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (150major+131minor)pagefaults 0swaps
[root@Linux /]$time /tmp/madplay test.mp3 MPEG Audio Decoder version 0.10.3 (beta) - Copyright (C) 2000 Robert Leslie test.mp3: 1959 frames decoded (0:51.1) 11.37user 0.31system 0:50.39elapsed 23%CPU (0avgtext+0avgdata 0maxresident)k 0inputs+0outputs (311major+52minor)pagefaults 0swaps
Here splay is better than madplay and these 'time' results are also coherent with what I get from 'top' statistics.
If I do a
cat /dev/zero > /dev/null &
I can actually see with 'top' that splay uses approx 18% CPU and the 'cat' process uses the 80% leftover. When madplay uses its 23% CPU, cat actually gets 75% CPU.
It's true that splay uses a different object when writing to a file instead of the audio device, but looking at the code it shouldn't make so a big difference...
I don't know what to think.
Nicolas