In the process of searching for a good way to test my UDA1341 audio driver, I just cleaned up splay's fixpoint support a bit and created a ramdisk image with splay on it.
Sorry Rob, but I couldn't resist comparing splay against madplay on a SA1100 CPU because of recent concerns about splay benchmarks, threads, etc.
So here are the results. Since my ramdisk doesn't have the 'time' command, I grabbed a 'top' screen while each players were running in the background.
madplay:
12:27am up 27 min, 1 user, load average: 0.17, 0.04, 0.01 11 processes: 10 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 23.8% user, 0.5% system, 0.0% nice, 75.5% idle Mem: 28140K av, 13328K used, 14812K free, 0K shrd, 6144K buff Swap: 0K av, 0K used, 0K free 3752K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 84 root 16 0 1272 1272 1176 S 0 23.8 4.5 0:11 madplay 85 root 1 0 872 872 704 R 0 0.5 3.0 0:00 top 1 root 0 0 512 512 440 S 0 0.0 1.8 0:02 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 34 root 0 0 500 500 436 S 0 0.0 1.7 0:00 syslogd 50 root 0 0 568 568 492 S 0 0.0 2.0 0:00 inetd 54 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 55 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 56 root 0 0 904 904 748 S 0 0.0 3.2 0:00 bash
splay:
12:29am up 29 min, 1 user, load average: 0.12, 0.05, 0.01 13 processes: 11 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 17.6% user, 0.5% system, 0.0% nice, 81.7% idle Mem: 28140K av, 13672K used, 14468K free, 0K shrd, 6144K buff Swap: 0K av, 0K used, 0K free 3752K cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND 86 root 14 0 904 904 536 R 0 17.0 3.2 0:08 splay 88 root 0 0 904 904 536 S 0 0.5 3.2 0:00 splay 89 root 1 0 872 872 704 R 0 0.5 3.0 0:00 top 1 root 0 0 512 512 440 S 0 0.0 1.8 0:02 init 2 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kswapd 3 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kflushd 4 root 0 0 0 0 0 SW 0 0.0 0.0 0:00 kupdate 34 root 0 0 500 500 436 S 0 0.0 1.7 0:00 syslogd 50 root 0 0 568 568 492 S 0 0.0 2.0 0:00 inetd 54 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 55 root 0 0 472 472 400 S 0 0.0 1.6 0:00 getty 56 root 0 0 904 904 748 S 0 0.0 3.2 0:00 bash 87 root 0 0 904 904 536 S 0 0.0 3.2 0:00 splay
Even if splay has 3 threads running, they account for 17.5% CPU vs 23.8% CPU for madplay. Both screen snapshots were taken at the same playback time so the "TIME" comparison should be accurate too.
The test file used is MPEG-1 Layer 3, joint stereo, 44100Hz, 128kbit/s.
This was tested on Linux 2.3.99-pre6-rmk1-np4. /proc/cpuinfo shows:
Processor : Intel StrongARM-1110 rev 5 (v4l) BogoMIPS : 194.15 Hardware : Intel-Assabet
The splay version I used is the cleaned one. Its playback performances is the same as the old one, however is starts right away instead of crunching 100% CPU for few seconds. This will produce proper results if mesured with the 'time' comands.
If you are interested, here are where you can find all relevant files:
splay-0.8.2-fp1.tgz ftp://ftp.netwinder.org/users/n/nico/ ramdisk_img_splay.gz ftp://ftp.netwinder.org/users/n/nico/ mad-0.10.3b.tar.gz ftp://ftp.mars.org/pub/mpeg/
Nicolas