Ville, the main developer of MenuetOS (a fully 32 bit assembly written, graphical OS, distributed under GPL) says:



I think this could benefit *all* the audio players (and maybe encoders ?).
Volunteer needed.

Contact him: jyu.


Happy coding !

There's sources available for FreeAmp here

Try amp11 by Niklas Beisert. It's written in C++ and the sources are very nice, clean and easy to understand. And last not least this implementation is quite efficient (nice algorithm optimizations).

http://www1.physik.tu-muenchen.de/~nbeisert/amp11.html

Or mpg123
http://www.mpg123.de

The library (i.e. MP3 decoding) part is under LGPL and written in clean C and optional Assembler optimizations

MAD Decoder is GPL and should be ideal for the project, because it includes assembly optimizations.
dev0

http://mpg321.sourceforge.net
A mpg123 clone completely under the GPL completely in C

This is not a decoder - it relies on the MAD libs for decoding.

--
GCP

Oh... you're right

Wonder if hardware mp3 players can benefit from this?

They still haven't got their act together regarding VBR...

Are you referring to the incorrect time display while searching? That's the only issue I have with vbr files and my hardware player.

No, my Sony D-CJ01 may have dropouts with some VBR files

ah, ok. My player's a car deck, JVC KD-SH99, and it has no problems playing them at all. That's the only thing it stumbles on, the time display is incorrect after searching through a vbr file.

he might wanna contact Emre Suat :
http://v2os.v2.nl/forum/viewtopic.php?t=14

With a lot of modern hardware, you aren't going to get much improvement from hand-written assembly over a good optimizing C compiler. In fact, with very large programs you might get worse performance, as the C compiler can scan millions of lines of code simultaneously while optimizing, while hand-optimizers usually only deal with small areas at a time. And with a CPU like the Itanium, it's almost impossible to write non-buggy assembler code in the first place, as you'd have to take care of the various problems pipelining introduces manually (on the x86, the hardware does this for you, at a significant cost to execution speed). If you absolutely must have assembly in your code, write the code in C or C++ or your other favorite language first, run a profiler on it to find where most of the execution time is being used up, and rewrite only those speed-critical routines in assembler. You'll get 99% of the benefits, with a fraction of the problems.

Of course I'm a fan of high-level programming, so I may be somewhat biased.

"He who hasn't hacked assembly language as a youth has no heart. He who does as an adult has no brain." -John Moore

and you can say that again..

i wonder how much experience do you have with assembly programming, real-time systems and code optimizations.. :eek:

I have a good bit of experience with both assembly programming and with code optimizations, but not with real-time systems. I agree that with real-time systems and many embedded systems, hand-coded assembler may still be both feasible and desirable -- mostly because you're still dealing with small code in small memory areas. Programming an embedded controller with 128K RAM today is not that much different than programming a PC in assembler was 20 years ago -- and 20 years ago, it was feasible to program a PC in assembler. Programming something like Mozilla in assembler, on the other hand, would be a complete nightmare.

With modern hardware (and by this I mean computers -- Pentium-class type stuff and better), this isn't the case. The vast majority of programs that need to be optimized will spend a very large percentage of their execution time in a very small percentage of the code. Hand-optimizing this very small part of the program is going to get you most of the efficiency gains that writing it in all assembler would have (often better than 95%), without the maintenance and portability nightmare (it's much easier to maintain and port a very small segment of assembler if the rest is in something else, like C). That's why id software writes their games in C and only write the speed-critical inner loops in assembler -- and they were even doing that back when the 386 was the machine of choice.

And even this much only works on architectures that either have no pipelining or implement pipelining in hardware. Software pipelining is much faster, and is likely to become more common in the future (this is what the Itanium uses). It's simply infeasible to write anything more than a very very simple program in assembler when you have to deal with software pipelining.

Watch yourself what a 100% Assembly OS can do in 1,44 Mb !
No other OS (except QNX), even Linux, can do somethig similar.

I do agree in essence with Delirium, sometimes it is more efficient just to optimise the most cpu intensive part...

However, some people code (& understand) Assembly easier than they do C/C++ (!?) (Avery Lee of VirtualDub being one of them....)

Personally coding in assembly drives me up the wall, but compilers like VC & gcc dont always write the best assembly code themselves, so if someone can write something like an MP3 Decoder completely in assembly, the compiled code will be very small & very fast.

I once put milldy modified mpg123 code just into one C++ class (one .h file & one .cpp file) (as a basis to learn from)....if its any use to they guy ill post a link......

-Nic

v2os is another good example.

@Delirium
maybe you should read some good assembly sources, where simd is being used to both implement controls (program flows) and processing (data manipulation).
back in 1997, i have written thousands of assembly lines for a DSP card, porting a pretty decent algorithm originally written in matlab, with mutlichannel processing (data manipulation) and lots of logics (program flows).
this was a realtime system, meaning, on each sample the system got in its multichannel input, it had to produce a relevant sample in the system's output (this, plus rs232 feedback status, lightning diodes and other blah-blah stuff).

true, i had to debug my code by.. printing the sources and reading and rereading it, true, it's also very hard to read this code - BUT, this code used more than 90% of the DSP resources (40 MIPS), and ANY compiler would have just fail here.
sure, we could have developed a new card, with newer CPU.. and eventually we did, but on that timeline - it wasn't an option.
oh, and btw, the new board had different DSP, different Assembly, and i had to port the code to this new Assmebly.
believe it or not, it took less than a month.

end of story -
developers could be better than compiler, 'cause the developers have the privilige to understand the algorithm, while the compilers don't.
developers knows which of the flags are needed at any part of the code, and compilers sometimes being too cautious, compilers hardly merge more than variable into one register, while developers can easily do this.
one of the best thing is seeing an assembly code that simply 'removed' all original variables from the original algorithm, and implemented a registers-only code.
i did it lots of times, and it's pure fun!