I got a little mp3 player from:
http://keyj.s2000.ws/ (there is also nanojpeg and some other tiny nifty utils)

it compiled and worked fine but it pulled in libm,

so I tried to compile it without libm and found it needed some trig functions - so I added the -ffast-math compiler flag and all it needed was "pow" both the gnu and uclibc were too big to include so I included pow from the libm in dietlibc and eureka. It now uses less than 2mb of ram and 0% cpu load and still weighs in at only 31k.

Edit - I compiled it with static dietlibc and it is even smaller only 30k and uses only 400kb of ram and 0% CPU (-ffast-math yields bad results with dietlibc so I removed it) ... both tarballs include source, build script and a public domain mp3 of a dog bark for testing

Version 2 plays like the singer had inhaled helium (that goes for the instruments as well), although the playback speed seems correct - like a very highly set high-pass-filter .

You should have heard it before I removed -ffast-math... oooo maybe I should check the package - I have had it happen before where a tarball gets an old (deleted) version that was in the same location due to weird unionfs voodoo magic..._________________Web Programming - Pet Packaging 100 & 101

I'm adding v3 which includes a build script that will allow 3 different compile types (just edit the script for the alternate builds)

gnu libc and libm
gnu libc and no libm by using -ffast-math and pow() from dietlibc
static dietlibc binary
(binaries for each type are included in the tarbal)

turns out my last dietlibc compile probably sounded bad because it used my newer dietlibc include headers but linked against Barry's older libs (I forgot dietlibc was in the devx and ended up with version mismatching)

Guys, I find this thread very interesting.
But just to add some context here: forum member pakt has been using mpg123 with the minimalist gui "xhippo" on his eBox-2300 with a paltry 200MHz processor and modest onboard graphics chip. That results in an acceptable 21% CPU usage:
http://www.murga-linux.com/puppy/viewtopic.php?p=306960#306960
What are you intending to run this on? A Linux-powered wrist-watch!

Has anyone actually compared this with mpg123? (for both ram and cpu usage)

If I was running either a 200MHz machine or a wristwatch I'd take anything extra I could get... sometimes I even get the urge to use an ultra-tiny mp3 player on this 1200MHz/512MB machine _________________DEATH TO SPREADSHEETS
- - -
Classic Puppy quotes
- - -
Beware the demented serfers!

Has anyone actually compared this with mpg123? (for both ram and cpu usage)

Yes, in lucid. minimp3 worked out of the box.

Code:

[module.c:126] error: Failed to open module alsa: file not found
[module.c:126] error: Failed to open module oss: file not found
[audio.c:179] error: Unable to find a working output module in this list: alsa,oss
[audio.c:533] error: Failed to open audio output module
[mpg123.c:773] error: Failed to initialize output, goodbye.
~ #

initially I only wanted it as a quick, reliable way to test audio functionality on systems independent of the library versions , but it is so out of the way that I kept it around to play tunes in the background (that's why I added the multiple file capability)... also because it is <64kb and runs less than 512kb it can stay mostly in cache on a lot of systems

There are a few binaries in Puppy that could immensely benefit from a static dietlibc build - mostly the always on items that run in the background like tray apps and the automounting daemon. The most obvious is sleep because it is using the inbuilt busybox sleep, so it takes up something like 2.5MB, but if compiled against dietlibc the bin is only 2kb and takes up 20kb in RAM... since Puppy mostly runs in RAM, this would be a net savings of over 2MB at no significant cost (btw does anyone know which program is actually running "sleep 2") ... others are init, udevd (has anyone experimented with replacing it with busybox's mdev?), dhcpcd, ash, and maybe even cups.

For comparison purposes, the static uclibc busybox build from http://impactlinux.com/aboriginal (formerly firmware linux) has double the number of applets that puppy's has and takes less ram to run because gnu libc and libm bring in over 1mb on their own. Using Rob Landley's builds we could double our applets and nearly half the RAM usage, but it may even be worth it to build a second (even smaller) busybox just for the daemonized applets. Some busybox alternatives are embutils(Felix von Leitner-dietlibc), asmutils(assembly-alinux), toybox(Rob Landley-aboriginal linux), toolbox(Google's replacement for busybox)... probably others?_________________Web Programming - Pet Packaging 100 & 101Edited_time_total