[MPlayer-dev-eng] [PATCH] replacement for internal mpg123 fork (mp3lib), Final version?

[Thomas Orgis]

Am Mon, 24 May 2010 01:49:40 +0200
schrieb Diego Biurrun <diego at biurrun.de>: 

> I built libmpg123 directly from svn and the performance difference is
> much smaller but still there. 

It is still _slower_? To further eliminate the impact of slow malloc,
can you increase the number in line 439 in
src/libmpg123/readers.c from

#define BUFFBLOCK 4096

To something (excessively) bigger? Perhaps this does something on the
K6. Otherwise, some profiling of mplayer would be helpful
-- to be sure that the decrease is really about the I/O, not the
decoding routines itself. The latter case would need more thought,
obviously.

I'll see if I can get my K6-3+ to cooperate. But I do remember that it
has some strange performance characteristics... namely: The CPU
supports extended 3DNow, but it's slower than normal 3DNow.
With an older install of mpg123, I see over 7 s decoding time for the
first track of the album mentioned below, while with plain 3dnow it's
6.6 s.

Can you compare
	mpg123 --cpu 3dnow -t file.mp3
with
	mpg123 --cpu 3dnowext -t file.mp3
? And consequently, mplayer with "3dnow" or "3dnowext" replaced for
NULL in
    con->handle = mpg123_new(NULL, &err);

I might need to insert some smartness in mpg123 _not_ to select
3DNowExt on K6 CPUs even if they support it.

> Before we go into detailed benchmarking
> I think we need to find a suitable set of test samples.

Have a look at:

http://mpg123.org/benchmarking.shtml

I'm using that one mentioned there:
http://www.jamendo.com/de/download/album/7328

I have the strong suspicion that you are seeing the effect of slow
extended 3DNow ...


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100524/87bdf7bc/attachment.pgp>