O-tone Michael Hipp: The mp3 benchmarking lie?----------------------------------------------Let's write a few notes about benchmarking the different mp3 decoders,which are available. 'top' is NOT a benchmark, it's a simple checkhow a program performs. The sad thing with 'top' is, that it has someproblems with the measurement of threaded programs of programs onlyrequesting short chunks of processor time. So, the only real test isprobably decoding a stream without threads with 100% CPU time andmeasure the time how long your machine needs for it.You can do this with mpg123 by doing a  time mpg123 -t mp3stream.mp3or  time mpg123 -s mp3stream.mp3  > /dev/nullif you additionally want to measure the I/O time. If you find a player, which claims to be 10 or even more times faster than thecurrent players: just don't believe it. A factor of 2 MAY BE possible.Thomas's mpg123 decision process--------------------------------I made some tests back then when I wondered  if there is a point in using another "modern" mp3 decoder for my mixing daemon. This was around Dec. 2004 till Feb. 2005 with current versions (0.59r-thorX in the case of mpg123). What follows is a copy of the DECODERS file in the dermixd distribution:What decoder should one use?----- MP3-----mpg123 is the old-fashioned way, uncertain license, may have some problems with extraordinary files (huge id3v2 tags, other specialities?), but fast. Has EQ control; interactive frontend interface (in parts hacked by me...).mpg321: is popular these days... interface? speed?madplay: is becoming popular these days, handles RVA2 by itself... can't provide an interface nor EQspeed:decoding Dirty Guitar with NULL output, pentium-optimized (not more):decoder	user time/smpg123	23madplay(hq)	46madplay(speed)	34mpg321(hq)	62mpg321(speed)	49So, there is still a strong technical point in using mpg123... even when my 366MHz-Laptop can easily handle several decoders at once with either of the programs, every percent cpu usage drags on the battery... and takes the cpu time from the real work----- OGG-----7,9M	/tmp/dirty_guitar-q3.ogg11M	/tmp/dirty_guitar-q5.ogg13M	/tmp/dirty_guitar-q6.ogg15M	/tmp/dirty_guitar-q7.ogg22M	/tmp/dirty_guitar-q9.ogg29M	/tmp/dirty_guitar-q10.ogg14M	/tmp/dirty_guitar-std.mp3101M	/tmp/dirty_guitar.wavspeed of ogg123:quality	user time/s3	315	366	387	3910	55So, with similar care as mpg123 concerning some (assembler?) optimization, ogg could well come close to "fast" mp3 decoding.Does ist sound better, then?A review from the new maintainer--------------------------------Now it's 2006, 23th of July. Still the same laptop, still the same mp3 file.I just want to update the number for current mpg123 with the mmx optimization.I should also see if competition (well, ogg, at least?) improved in the year that passed... but looking only at mp3, that reduces to the question if mpg123 got faster or slower.Neither on the mpg321 site or the MAD site (ftp dir) did I find any new version. MAD is still 0.15.1b (0.15.2b for madplay), mpg321 still 0.2.10 .Well, I can look at mplayer's mpg123 spawn called mp3lib that has been taken care for over the time.But apart from that, will mpg123 stand alone on the field of console mp3 engines that are actively maintained???To have at least some twist, I now measured the output of raw data to stdout (to /dev/null) instead of decoding alone. The hardware and largely the software is still the same (now kernel 2.6.11 instead of 2.6.?).I've only used the "high quality" mad players - the earlier measurements give a hint about the difference to the "speed" variant.mpg123-0.60-beta1, underworld_@_dirty_guitar.mp3gcc-3.3.3CFLAGS=-O2 -finline-functions -march=pentium2built with the new autoconf/make systemmachine in X11 running fluxbox, no active load (like a year ago)measuring second run (with cached file)time for -s > /dev/null decode...pentium:	24spentium, MMX:	19spentium, MMX, gapless (runtime-disabled): 19spentium, MMX, gapless (also runtime-enabled): 19smpg321 0.2.10, high quality: 64smadplay 0.15.2b, high quality: 56sWith the file length being m:s 9:58 (598s), for mpg123 that makes theoretical realtime cpu 3-4% for the PII-366.Incidentally, `top` agrees there: it shows 3.0-3.3% CPU usage for the MMX/gapless binary during normal OSS playback.I feel unable to benchmark the mp3 playback of mplayer - I don't see an option to make it decode audio as fast as possible (I only know -benhcmark and -noaudio; with esp. the latter not helping me there).