[Mplayer-dev-eng] [Experimental PATCH] downmix_3dnow.S

[Arpi]

Hi,

> >> I know it. There are a tons of pure C code in time-critical imdct.c+srfft.c+...
> >> But I still have no ac3 samples - may be later, I hope.
> >> What you think about adding to mplayer possibility to playback a pure
> >> audio streams (like mp3, ac3 and so on)? Such feature could make optimization
> >> easy on top small samples.
> >I'm already working on this. It requires for .wma playback too.
> >
> As soon it will be available?
Not soon. But I'll make a simple playmp3 and playac3 stuff, it's about
a page of code... Just to play (or optionally only decode, no play)
audio steram for benchmarking and testing.

> >> And last moment: Mplayer has imported libraries such as (libmp3, libac3, ...). They probably have
> >> own centres of development. Did you ask their authors about expanding mmx-optimized code?
> >> And how you plan to synchronize those projects later?
> >mp3lib is my stuff, i made it for my own mp3 player about 2 year ago,
> >and still using it for our 3d demo engine too.
> >it's synced with latest mpg123 version. i dunno that mpg123 is still developed,
> >but i think it isn't.
> >
> I did't know that mp3lib is your stuff...
> But I've found several copies of mp3lib in inet: mplayer, xmms, mpg123-0.59r and somewhere else
> and there were slightly different sources. IMHO mp3 is quite complete - it's probably lacks
> only SSE support - but it's not very difficult work ;)
my mp3lib != mpg123's mpglib

mp3lib was derived from very old mpg123 (when mpglib didn't exist) for DOS
(!) for my old DOS SB16/GUS TSR mp3 player. Then I ported it back to linux
and updated layer3.c and others from current mpg123. It was modified to
fit my linux mp3 player, called '3pm'. Later it was modified again to fit
our 3D demo engine ('astral demo system'). And finally it was used for
mplayer too.

in contrast, mpglib was developed by mpg123 author, for a company, but its
available as GPL. It has nothing common with my mp3lib, except that both
libs based on mpg123 sources.

> >libac3 is much interesting. it has some newer version, but they are
> >incompatible with the old (used by mplayer), and it's a hard work at every
> >sync to change it.
> Are there improvements in stream reading or something else?
> I.e. would you like synchronize with libac3 in the future?
Maybe there are improvements in decodig speed or quality, maybe dolby
support finished. I don't know, not checked it for a while.
Stream reading can't be improved, I think. In version used in mplayer, it's
already optimized (using fast macros, etc), and it's stable enough (CRC
checking etc).

Unfortunately they reversed the main loop, in old libac3 the decoder was
called from player loop (like a codec), but in their current version the
libac3 is the main loop, and it callbacks only to the player. It's usable
only in multithreaded player or audio-only players :(

If it worth, I can rewrite their decode.c and other stuff to fit our needs.
Btw it seems to libac3 development stopped after Aaron leaved the scene.
(libmpeg2 also stopped for a while, but now Walken continues it)
 
> >(new version uses callback for playback instead of stream reading)
> Yes, xmms uses thread for playback too. It has several pluses:
> - reading ahead from the stream
> - real-time playback on top loaded cpu.
> Maybe it would reasonable to change logic of mplayer on the same?
Maybe. But we must change everything to thread-safe, it's a big speed loss!

read ahead: i prefer buffering of the whole input than only audio.
play on top load: audio cards have avg 0.3-1.5 sec buffer, it must be enough.

> >I'm usually sync
> >- loader: mereg from avifile-CVS after big changes
> But why not from wine?
code in wine is unable to handle these dlls well... its goal is something
else. aviplay's dll loader was derived from wine and strongly changed to
make it rock solid and independent from other wine stuff.
wine emulates the whole win32 api, it's too lot for us. for example:
there aer calls to get current path, windows version, various proecss
statsu info etc. tehy are all implemented in wine, but they aren't really
requires for tehse codecs DLLs, but they are called! codecs usually call
these but don't rely on results. avifile's dll loader has _minimal_
implementation of these, enough for codecs. So it's less complex and more
stable.

> >> P.S.: Mplayer (and its imported parts) contains a places which can be optimized with using 
> inline-assembler.
> >> Does mplayer run on non Intel architectures (at least with code which not required win32.dll)?
> >No. And it wasn't planned to be portable. I think that mpg12player should be
> >ported if someone interested. it's the parent of mplayer, and supports mpeg
> >1/2 playback only.
> >
> >> It would be better to add in mplayer something like HAVE_IA32 and HAVE_CPU=3(4,5,6) to enable such
> >> assembler optimization. HAVE_CPU or likewise should be numeric for
> >> #if HAVE_CPU > 3 constructions.
> >> May you have any ideas about names such macros. (For compatibility with further importing, addition and 
> >> synchronizing)
> >Good idea.
> >
> Maybe you'll add these or likewise macros to configure?
yes i can. but it's simple, you can do it too.


A'rpi / Astral & ESP-team

--
mailto:arpi at thot.banki.hu
http://esp-team.scene.hu

_______________________________________________
Mplayer-dev-eng mailing list
Mplayer-dev-eng at lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/mplayer-dev-eng