First, what's standard etiquette for using a mailing list? Do I respond to both the person and the list, or just the list, or what?
It actually works? what modification did you make to the code, especially huffman.c ?
Yup, works fine. The main patches to huffman.c were changing PTR for huffquad and huffpair:
// huffquad PTR macro
# define PTR(offs, bits) { { \ 0, \ bits, \ (offs & 1) >> 0, \ (offs & 2) >> 1, \ (offs & 4) >> 2, \ (offs & 8) >> 3, \ (offs & 0xFF0) >> 4 \ } }
// huffpair PTR macro
# define PTR(offs, bits) { { \ 0, \ bits, \ (offs & 0x000F) >> 0, \ (offs & 0x00F0) >> 4, \ (offs & 0x0F00) >> 8 \ } }
This'll probably only work on little-endian machines.
Of course, there were several other minor changes. One of these days I'll build a patch and submit it to Rob.
For now, use anonymous CVS:
CVSROOT=:pserver:anonymous@pyrallis.aegisknight.org:d:/cvsroot
cvs login Password: guest
cvs co acoustique
One last note... I *attempted* to port FPM_INTEL to VC++ (renaming it to FPM_INTELVC)... However, my ports of the asm() directives never worked. :) Also, FPM_64BIT was about four or five times slower than FPM_DEFAULT. So if you're compiling with VC++, you *definitely* want FPM_DEFAULT.
--- Chad Austin aegis@aegisknight.org wrote:
Of course, there were several other minor changes. One of these days I'll build a patch and submit it to Rob.
You wouldn't be the first to suggest fixes for this.... So far Rob seems quite happy to stay gcc specific though :-)
One last note... I *attempted* to port FPM_INTEL to VC++ (renaming it to FPM_INTELVC)... However, my ports of the asm() directives never worked. :)
For FPM_INTEL, apart from MAD_F_MLX, all the macros are 'statement expressions' which are a sort of cross between a macro and an inline function, and are very gcc specific. The fact that they also contain gcc specific inline assembler means getting them to run with another compiler requires more of a 'rewrite' than a 'port' :-)
Also, FPM_64BIT was about four or five times slower than FPM_DEFAULT. So if you're compiling with VC++, you *definitely* want FPM_DEFAULT.
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
Andre --
____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
En réponse à Andre armccurdy@yahoo.co.uk:
--- Chad Austin aegis@aegisknight.org wrote:
Of course, there were several other minor changes. One of these days I'll build a patch and submit it to Rob.
You wouldn't be the first to suggest fixes for this.... So far Rob seems quite happy to stay gcc specific though :-)
One last note... I *attempted* to port FPM_INTEL to VC++ (renaming it to FPM_INTELVC)... However, my ports of the asm() directives never worked. :)
For FPM_INTEL, apart from MAD_F_MLX, all the macros are 'statement expressions' which are a sort of cross between a macro and an inline function, and are very gcc specific. The fact that they also contain gcc specific inline assembler means getting them to run with another compiler requires more of a 'rewrite' than a 'port' :-)
If only I could get a Makefile with cygwin, I could start trying to get MAD working in VC++. But I downloaded the latest cygwin version and when I run ./configure it tells me that GCC is present but cannot make excutables (!). Maybe that's my cygwin installation that is wrong. But if anybody could send me the working Makefile (for each dir) that would save me that time ;)
Also, FPM_64BIT was about four or five times slower than FPM_DEFAULT. So if you're compiling with VC++, you *definitely* want FPM_DEFAULT.
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
VC++ can deal with 64bit integers there is a __int64 MS specific type. (which won't work with Borland compilers :( ) Otherwise assembly (MMX) could help.
steve.lhomme@free.fr wrote:
If only I could get a Makefile with cygwin, I could start trying to get MAD working in VC++. But I downloaded the latest cygwin version and when I run ./configure it tells me that GCC is present but cannot make excutables (!). Maybe that's my cygwin installation that is wrong. But if anybody could send me the working Makefile (for each dir) that would save me that time ;)
Since you asked so nicely :-) (Fixing your cygin setup may be more useful in the long run...).
VC++ can deal with 64bit integers there is a __int64 MS specific type. (which won't work with Borland compilers :( ) Otherwise assembly (MMX) could help.
If you're going to do something x86 specific, re-writing a few key sections with floating point might be a more interesting exercise...
Andre --
____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
En réponse à Andre armccurdy@yahoo.co.uk:
steve.lhomme@free.fr wrote:
If only I could get a Makefile with cygwin, I could start trying to get MAD working in VC++. But I downloaded the latest cygwin version and when I run ./configure it tells me that GCC is present but cannot make excutables (!). Maybe that's my cygwin installation that is wrong. But if anybody could send me the working Makefile (for each dir) that would save me that time ;)
Since you asked so nicely :-)
Thanx !
(Fixing your cygin setup may be more useful in the long run...).
I've tried a bit. The problem seems to be that the configure script tries to run gcc with no other parameters and so it gets an error. Maybe I'm missing some additional parameters to the script or some config parameters.
VC++ can deal with 64bit integers there is a __int64 MS specific type. (which won't work with Borland compilers :( ) Otherwise assembly (MMX) could help.
If you're going to do something x86 specific, re-writing a few key sections with floating point might be a more interesting exercise...
Isn't MAD suposed to be float free (as much as possible) ?
steve.lhomme@free.fr wrote:
VC++ can deal with 64bit integers there is a __int64 MS specific type. (which won't work with Borland compilers :( ) Otherwise assembly (MMX) could help.
If you're going to do something x86 specific, re-writing a few key sections with floating point might be a more interesting exercise...
Isn't MAD suposed to be float free (as much as possible) ?
Yes. To be usable on embedded targets (ARM, low end MIPS, etc) MAD should avoid all floating point stuff.
However, if you are going to make x86 specific changes which can never be used on these embedded targets (eg MMX rewrites) then why stick with the no floating point restriction ??
Andre --
____________________________________________________________ Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie
On Thu, 31 May 2001, Andre wrote:
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
What's wrong with using gcc for Windows (Cygwin) then? There is certainly a way to wrap libmad with a compatible CV++interface and link against it.
Nicolas
I'd like to have a portable library that builds in lots of compilers. Yeah, gcc is everywhere, but few people actually use gcc for Windows development. Getting libmad to compile and work in Visual C++ and maybe C++Builder is clearly useful, IMO.
Nicolas Pitre wrote:
On Thu, 31 May 2001, Andre wrote:
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
What's wrong with using gcc for Windows (Cygwin) then? There is certainly a way to wrap libmad with a compatible CV++interface and link against it.
Nicolas
One last note... I *attempted* to port FPM_INTEL to VC++ (renaming it to FPM_INTELVC)... However, my ports of the asm() directives never worked. :)
For FPM_INTEL, apart from MAD_F_MLX, all the macros are 'statement expressions' which are a sort of cross between a macro and an inline function, and are very gcc specific. The fact that they also contain gcc specific inline assembler means getting them to run with another compiler requires more of a 'rewrite' than a 'port' :-)
Statement expressions are easy to convert. You just make them inline functions (which gcc supports too).
The assembly stuff should have been relatively easy to port, because VC++'s __asm lets you access C expressions from the assembly. I'm not too experienced with x86 assembly so I was just trying to hand convert the stuff over. Of course, it didn't work, so I just gave up. I'll deal with it later. :)
Also, FPM_64BIT was about four or five times slower than FPM_DEFAULT. So if you're compiling with VC++, you *definitely* want FPM_DEFAULT.
Hmmm. FPM_DEFAULT should only be considered as a very last resort for compilers/architectures which don't allow access to the top 32bits of the 64bit result of a 32x32bit multiply. It loses significant accuracy, and is best avoided. If you can't get VC++ to work efficiently with 64bit signed integers, then MAD probably isn't the decoder to use.
I talked with a friend from Iowa State (he's a pretty crazy assembly guru, worked for AMD last summer) and he said that VC++ really sucks at optimizing 64-bit integers.
I'm using MAD because it's GPL and it works. :) It takes me between 3 and 4 percent of my CPU to decode an MP3, which is more than acceptable. FPM_64BIT took between 14 and 20... If you want to help me fix up FPM_INTELVC... :)
On Thu, 31 May 2001 00:49:31 -0800, Chad Austin aegis@aegisknight.org wrote:
Hi,
First, what's standard etiquette for using a mailing list? Do I respond to both the person and the list, or just the list, or what?
I would suggest, only reply to the list.
It actually works? what modification did you make to the code, especially huffman.c ?
[...]
Of course, there were several other minor changes. One of these days I'll build a patch and submit it to Rob.
For now, use anonymous CVS:
CVSROOT=:pserver:anonymous@pyrallis.aegisknight.org:d:/cvsroot
cvs login Password: guest
cvs co acoustique
just made a patch, if anyone is interested to look at them: http://www.asamnet.de/~finkm/mad-patch.diff
In my opinion, there are some changes that are unnecessary, for example the introduction of the symbol MAD_EXTERN_C. since *.c files are always compiled using extern "C" linkage (at least in VC++), that is unneeded I think. Just list your exports in a separate .def file.
Another thing are constructs like #ifdef _MSC_VER /* VC++ */ #define MAD_INLINE __inline #else /* assume gcc */ #define MAD_INLINE inline #endif
just provide a custom config.h, define HAVE_CONFIG_H and all things will be good :-) I could provide one for win32 I anyone cares
The type casts on the functions are ok I think, it makes the VC++ not warn so often, maybe Rob considers it to build it into libmad
bye Michael
just made a patch, if anyone is interested to look at them: http://www.asamnet.de/~finkm/mad-patch.diff
Cool, thanks for atually doing the work. :)
In my opinion, there are some changes that are unnecessary, for example the introduction of the symbol MAD_EXTERN_C. since *.c files are always compiled using extern "C" linkage (at least in VC++), that is unneeded I think. Just list your exports in a separate .def file.
Well... I added those because Acoustique is C++, and I would do:
#include "resample.h" // the functions in here weren't extern "C" so // the C++ compiler would assume the names were mangled
Trust me, it is necessary. :)
Another thing are constructs like #ifdef _MSC_VER /* VC++ */ #define MAD_INLINE __inline #else /* assume gcc */ #define MAD_INLINE inline #endif
just provide a custom config.h, define HAVE_CONFIG_H and all things will be good :-) I could provide one for win32 I anyone cares
That's fine, even though I really don't like config.h files. I'd be perfectly happy if libmad got a config file that let it build "out of the box" in VC++ though. :)
The type casts on the functions are ok I think, it makes the VC++ not warn so often, maybe Rob considers it to build it into libmad
I added those because I was trying to build with warning level four, but VC++ really, really sucks in that warning level four starts giving you a bunch of useless information like "This inline function is never used." I couldn't get around that without uncommenting the inline function, so I just put it back on level three. When VS .NET comes out (man that will be nice) all of these problems will be fixed, so we can stick it back on warning level four. :)
On Thu, 31 May 2001 11:35:35 -0800, Chad Austin aegis@aegisknight.org wrote:
Hi,
In my opinion, there are some changes that are unnecessary, for example the introduction of the symbol MAD_EXTERN_C. since *.c files are always compiled using extern "C" linkage (at least in VC++), that is unneeded I think. Just list your exports in a separate .def file.
Well... I added those because Acoustique is C++, and I would do:
#include "resample.h" // the functions in here weren't extern "C" so // the C++ compiler would assume the names were mangled
Trust me, it is necessary. :)
Not necessarily :)
to access the library functions, I built a mad.h from the mad.h.sed script (using my linux box), edited that file a bit:
// C linkage for all functions #ifdef __cplusplus extern "C" { #endif
[...]
#ifdef __cplusplus } #endif
and it works with C and C++ :-)
If you like, I could upload a little demo project where libmad is built and a little example program tries to open an mp3 and decodes it. "tries to", because all I got from that mp3 file are samples with 0's :-)
Ok, I've uploaded the little example with a prebuilt release libmad.dll: http://www.asamnet.de/~finkm/minimad.zip
bye Michael
-
Andre -
Chad Austin -
Michael Fink -
Nicolas Pitre -
steve.lhomme＠free.fr