Hi all!

I've ported lame and mpg321 to the openwrt.
Our goal at first was to check if it was realistic to play mp3 and ogg real time on the board..

But here, with wrt54g v1.0, results are really poort: 0.0025x real time for mp3 encoding with lame, and 0.15x for mp3 decoding with mpg321..

What we'd like to know is:
-- Can anyone get better result with another supported board?
-- Is there important optimisation we should have overlooked?
The packages are allready in the tracker...

Thanks for your help!

Romain

Can you provide a patch or an archive or your mpg321 port, so that we can include it in our future releases?

(Last edited by Nico on 9 Dec 2005, 11:09)

I've been using madplay for mp3 decoding .. no issues so far

Yes of course!

I don't have time today but I'll do it ASAP

Romain

Do you have a package for this? I can't find any on the tracker..
Was it real time?

Romain

I still need to get around to packaging it; it was just a quick thing I did for a technology demo. Yes, it works realtime .. madplay is highly optimized; I was using a set of USB speakers and streaming internet radio. I found that if I tried to play mp3s off a USB thumb drive there was an occasional gap,  copying them to ramdisk or using an actual (non flash) USB drive resulted in flawless playback -- there's probably some option to turn on buffering but I really didn't look into it.

Well this is a GREAT news!

I will try madplay and provide a package I think.
BTW, madplay is based upon libmad, that I've packaged too -- and now I get why there is a tarball of it in your archives

So in order to try to get the same speed as you, I would like to know:
-- Did you used some special configure options for libmad?
-- On what board did you try it?

Romain

root@OpenWrt:~# time madplay -o /dev/null ./09\ -\ Derrick\ Morgan\ -\ Send\ a\ Little\ Rain.mp3
MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al.
          Title: Send a Little Rain
         Artist: Derrick Morgan
          Track: 09
        Comment: Artist unsure
6178 frames decoded (0:02:41.3), -0.1 dB peak amplitude, 0 clipped samples
real    1m 0.50s
user    0m 59.77s
sys     0m 0.60s

The song was 2m 41 long!

Well, with madplay, the difference is really important!!!!!

Thank you very much for that hint!

Packages are in my repository, and I will send patches when I'll have time to produce clean diff.

Romain

(Last edited by toots on 12 Dec 2005, 10:59)

Just send an archive of your package/madplay if you don't have much time.

Thanks for your help

Well, you can find them at:
http://www.cti.ecp.fr/~beauxir5/peercast/ if you are looking for the .ipk files.

BTW, I was wondering a thing about the decoding benchmark:
mpg321 and madplay use the same lib for decoding, so I can hardly figure out why it should be that different between them..
BUT, mpg321 uses pthread too, so I was wondering if pthread could be the bottleneck?

Romain

The bottleneck is probably floating point arithmetic. Since your linksys doesn't have an FPU you will take a beating on any floating point extensive program.
Luckily libmad is written entirely using fixed point arithmetic.

There has been quite a bit of work on iPodlinux with getting things to play realtime with similar cpu power.  Might want to check it out.

Geoff

Yep, but as far as I can get from mpg321, I get:

root@OpenWrt:~# ldd mpg321
        libid3tag.so.0 => /usr/lib/libid3tag.so.0 (0x2aaee000)
        libmad.so.0 => /usr/lib/libmad.so.0 (0x2ab3f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x2ab95000)
        libao.so.2 => /usr/lib/libao.so.2 (0x2abe5000)
        libdl.so.0 => /rom/lib/libdl.so.0 (0x2ac29000)
        libgcc_s.so.1 => /rom/lib/libgcc_s.so.1 (0x2ac6b000)
        libc.so.0 => /rom/lib/libc.so.0 (0x2acba000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x2ad5c000)
        ld-uClibc.so.0 => /rom/lib/ld-uClibc.so.0 (0x2aaa8000)

So, the time gap does not seems to come from fixed point/ floating point.
It was quite sure since both decoders rely on the same lib for decoding.

Romain

(Last edited by toots on 10 Dec 2005, 20:26)

afaik there are no integerized mp3 encoders yet? only integerized players.

Hi all!

I've finally done the same benchmark for vorbis decompression:

root@OpenWrt:~# time cat 02\ -\ Muslin\ Praise\ -\ Premiere\ Recolte.ogg | ivorbisfile_example > /dev/null
Artist=Sinsemilia
Title=Muslin Praise
Album=Premiere Recolte
Genre=Reggae
TrackNumber=2
Content group description=Reggae

Bitstream is 2 channel, 44100Hz

Decoded length: -131 samples
Encoded by: Xiph.Org libVorbis I 20030909

real    1m 32.60s
user    0m 0.06s
sys    0m 0.49s
Done.

The song was 3m 56 long!

It is based upon vorbis fixed point implementation found at http://www.xiph.org/vorbis/
You can grab the shared libraries -- libvorbisidec, and the test program (staticaly linked) -- ivorbis, in my repository, and in the tracker.

Romain