(old)Puppy Linux Discussion Forum

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

Dear technosaurus,

Nice, and thanks. Both versions work in Puppy 3.01 and 4.x. I also compiled nanojpeg, and it weighs in at 14k stripped (19k unstripped). I have yet to try it.

With kind regards,
vovchik

Hello !
Tested on musical .mp3s in ttuuxxx' 214XRC5:

Version 1 plays nicely .

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 .

Thanks for this player, from this minimalist at heart /
MHHP

MinHundHettePerro wrote: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...

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)

Tested all 3 in 431: The two gnuc-versions sounds equal (good....)
The dietstatic build has some (not unpleasant...) distortion...
I really like this tiny but basic and useful application!

gnu libc and libm worked well in Lupu. Compared with gnome-mplayer, using mini saved 58M RAM when playing an mp3 track.

(not unpleasant...) distortion...

since I am targeting this at lower end PCs, I thought it would be nice to be able to play a list of files or *.mp3 .... yes this could easily be done with a script

for x in `ls ./*.mp3`; do minimp3 $x; done

but that keeps the shell open the entire time which uses 4x the RAM as the static dietlibc version

so I added a for loop to main (it probably needs to be fixed up to pull unnecessary stuff out of the loop and such)

so now you can do this instead
minimp3 `ls ./*.mp3` &

or even drag a bunch of selected files to it (it sits nicely on my desktop now)

disciple wrote:

(not unpleasant...) distortion...

Yah - like being in a tube with a psychedelic rock band...
Some audio-players have that as a feature (like "bathroom-effect")...

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/viewto ... 960#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

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

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

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?

Hello !

Testing your newer versions in 214XRC5:

Ver. 3&4;
the gnu-versions work immaculately ,
the statics sound like Donald Duck on acid killed the singer, took over the mic, ripped the drums, and wrapped the rest of the band in duct tape .

Comparison of resources of minimp3 and mpg321, tested on a 2.8GHz,1Mb, 214XRC5 machine:
CPU
idling at 0.7-1.3%
minimp3 1.3-2.0%
mpg321 2.0-4.0%
Memory
Impact not discernible with htop (in cache?)

hth /
MHHP

Impact not discernible with htop (in cache?)

That's why I didn't try to compare it myself

disciple wrote:

Impact not discernible with htop (in cache?)

That's why I didn't try to compare it myself

Hey.. there's a difference; this is for the high quality mini using gnu libc and libm.

mpg321: 55M 6% CPU
minimp3: 48M 2% CPU

Any chance to include support for .au and .wav-play? Think both can just be send to /dev/audio or /dev/dsp via cat but might not play all files correct though...

goingnuts wrote:Any chance to include support for .au and .wav-play? Think both can just be send to /dev/audio or /dev/dsp via cat but might not play all files correct though...

I can't code it but if you can point me to a small standalone example(s), I may be able to hack it in there. I'd also need a C example to parse the file extension.

I found wavplay, but it needs a lot of hacking down - still contains quite some bloat, but I compiled it statically against dietlibc if anyone wants it.

http://sourceforge.net/projects/wavplay/files/

edit: bplay is a little better size wise and plays other formats too