mad-dev

mad-dev@lists.mars.org

682 discussions

New mailing list software
by Rob Leslie 01 Feb '01

01 Feb '01

This message serves both as a test and as an announcement of new mailing list software that is managing the mad-dev and mad-user mailing lists. If all went well, the transition should be pretty seamless. You can now manage your subscription from one of these pages: (mad-dev) http://www.mars.org/bin/mailman/listinfo/mad-dev (mad-user) http://www.mars.org/bin/mailman/listinfo/mad-user To make changes, first click the button to have your password mailed to you. As a bonus, both lists now have an online archive of past messages: (mad-dev) http://www.mars.org/mailman/public/mad-dev/ (mad-user) http://www.mars.org/mailman/public/mad-user/ Please let me know if you experience any problems. Cheers, -- Rob Leslie rob(a)mars.org

1 0

powerpc tuning
by David Blythe 31 Jan '01

31 Jan '01

We did some tuning for an embedded powerpc platform. FPM_64BIT works fairly well, the assembly tuning and changes to imdct36() improve things by another 60% or so over FPM_64BIT using gcc -O3. Performance with and without OPT_ACCURACY are pretty close, but OPT_SSO is still somewhat faster (~5%). There are 3 sets of changes: 1) changes to mad/configure and mad/libmad/configure to recognize --host=powerpc setting FPM_PPC; to allow -O3 to be set as an optimization level; and also to not wipe out the CFLAGS setting before running mad/libmad/configure (otherwise OPTIMIZER doesn't get set in libmad/Makefile). 2) additions to mad/libmad/fixed.h for asm coded PPC routines 3) modifications to layer3.c:imdct36() to use mad_f_mla for longer mac sequences if mla is available. The mla code is written such that the MLA macros could simply be redefined to use the regular mad_f_mul() code when the mla routine isn't available, but i chickened out and left the original code as an ifdef. diffs attached. patch -p0 < diffs from inside the mad-0.11.4b directory should do it. david Index: configure =================================================================== diff -u -r1.1.1.1 -r1.3 --- configure 2001/01/31 03:19:46 1.1.1.1 +++ configure 2001/01/31 04:24:18 1.3 @@ -1061,6 +1061,7 @@ arm-*) ARCH="-march=armv4 -mtune=strongarm" ;; mips-*) ARCH="-mips3" ;; #-mcpu=vr4100 + powerpc-*) ARCH="" ;; esac fi @@ -1069,10 +1070,11 @@ esac case "$CFLAGS" in + *-O3) OPTIMIZER="-O3" ;; *-O*) OPTIMIZER="-O2" ;; esac -CFLAGS="" +CFLAGS="$OPTIMIZER $DEBUGGER $PROFILER" if test -n "$OPTIMIZER" && test "$GCC" = yes then Index: libmad/configure =================================================================== diff -u -r1.1.1.1 -r1.3 --- libmad/configure 2001/01/31 03:19:46 1.1.1.1 +++ libmad/configure 2001/01/31 04:24:18 1.3 @@ -1086,6 +1086,7 @@ arm-*) ARCH="-march=armv4" ;; mips-*) ARCH="-mips3" ;; #-mcpu=vr4100 + powerpc*-*) ARCH="" ;; esac fi @@ -1094,6 +1095,7 @@ esac case "$CFLAGS" in + *-O3*) OPTIMIZER="-O3" ;; *-O*) OPTIMIZER="-O" ;; esac @@ -1630,6 +1632,7 @@ arm-*) FPM="ARM" ;; mips-*) FPM="MIPS" ;; sparc*-*) FPM="SPARC" ;; + powerpc*-*) FPM="PPC" ;; esac ;; @@ -1639,6 +1642,7 @@ sparc) FPM="SPARC" ;; 64bit) FPM="64BIT" ;; approx) FPM="APPROX" ;; + powerpc) FPM="PPC" ;; *) { echo "configure: error: bad --enable-fpm option" 1>&2; exit 1; } ;; @@ -1653,6 +1657,7 @@ arm-*) FPM="ARM" ;; mips-*) FPM="MIPS" ;; sparc*-*) FPM="SPARC" ;; + powerpc*-*) FPM="PPC" ;; # FIXME: need to test 64-bit long long... *) echo "configure: warning: using fixed-point math approximations (see README)" 1>&2 Index: libmad/fixed.h =================================================================== diff -u -r1.1.1.1 -r1.2 --- libmad/fixed.h 2001/01/31 03:19:46 1.1.1.1 +++ libmad/fixed.h 2001/01/31 04:02:51 1.2 @@ -268,6 +268,79 @@ : "%r" (x), "rI" (y)); \ mad_f_scale64(__hi, __lo); \ }) + +# define MAD_F_SCALEBITS MAD_F_FRACBITS + +# elif defined(FPM_PPC) + +/* + * This PowerPC version is tuned for the 4xx embedded processors. It is + * effectively a tuned version of FPM_64BIT. It is a little faster and + * just as accurate. The disposition of the least significant bit depends + * on OPT_ACCURACY via mad_f_scale64(). + */ +# define mad_f_mul(x, y) \ + ({ mad_fixed64hi_t __hi; \ + mad_fixed64lo_t __lo; \ + asm ("mulhw %1, %2, %3\n\t" \ + "mullw %0, %2, %3" \ + : "=&r" (__lo), "=&r" (__hi) \ + : "%r" (x), "r" (y)); \ + mad_f_scale64(__hi, __lo); \ + }) + +# define MAD_F_HAVEMLA +# define mad_f_mla(hi, lo, x, y) \ + ({ mad_fixed64hi_t __hi; \ + mad_fixed64lo_t __lo; \ + asm ("mulhw %1, %2, %3\n\t" \ + "mullw %0, %2, %3" \ + : "=r" (__lo), "=r" (__hi) \ + : "%r" (x), "r" (y)); \ + asm ("addc %0, %1, %2" \ + : "=r" (*lo) \ + : "%r" (__lo), "0" (*lo)); \ + asm ("adde %0, %1, %2" \ + : "=r" (*hi) \ + : "%r" (__hi), "0" (*hi)); \ + }) + +# if defined(OPT_ACCURACY) +/* + * This is accurate and ~2 - 2.5 times slower than the unrounded version. + * We let the compiler deal with putting the constant in a register + * since the value of MAD_F_SCALEBITS is redefined in some parts of the + * code and tracking the magnitude of (1<<(MAD_F_SCALEBITS-1)) is too + * complicated. + * The __volatile__ improve the generated code by another 5% (fewer + * spills to memory), eventually they should be removed. + */ +# undef mad_f_scale64 +# define mad_f_scale64(hi, lo) \ + ({ mad_fixed_t __result; \ + mad_fixed64hi_t _hi; \ + mad_fixed64lo_t _lo; \ + asm __volatile__ ("addc %0, %2, %4\n\t" \ + "addze %1, %3" \ + : "=r" (_lo), "=r" (_hi) \ + : "r" (lo), "r" (hi), "r" (1<<(MAD_F_SCALEBITS-1))); \ + asm __volatile__ ("rlwinm %0, %2,32-%3,0,%3-1\n\t" \ + "rlwimi %0, %1,32-%3,%3,31" \ + : "=&r" (__result) \ + : "r" (_lo), "r" (_hi), "I" (MAD_F_SCALEBITS)); \ + __result; \ + }) +# else +# undef mad_f_scale64 +# define mad_f_scale64(hi, lo) \ + ({ mad_fixed_t __result; \ + asm ("rlwinm %0, %2,32-%3,0,%3-1\n\t" \ + "rlwimi %0, %1,32-%3,%3,31" \ + : "=r" (__result) \ + : "r" (lo), "r" (hi), "I" (MAD_F_SCALEBITS)); \ + __result; \ + }) +# endif /* OPT_ACCURACY */ # define MAD_F_SCALEBITS MAD_F_FRACBITS Index: libmad/layer3.c =================================================================== diff -u -r1.1.1.1 -r1.2 --- libmad/layer3.c 2001/01/31 03:19:46 1.1.1.1 +++ libmad/layer3.c 2001/01/31 04:02:51 1.2 @@ -1253,6 +1253,294 @@ mad_fixed_t t6, t7, t8, t9, t10, t11; mad_fixed_t t12, t13, t14, t15, t16, t17; +#ifdef MAD_F_HAVEMLA + mad_fixed64hi_t hi; + mad_fixed64lo_t lo; + +#define MLA(res, first, acc) \ + hi = lo = 0; \ + acc; \ + res = first + mad_f_scale64(hi, lo) + +#define MLA_STEP(x, y) \ + mad_f_mla(&hi, &lo, x, y); + + t6 = + mad_f_mul(X[4], 0x0ec835e8L) + + mad_f_mul(X[13], 0x061f78aaL); + + t0 = t6 + + (t7 = mad_f_mul((t16 = X[1] - X[10]), -0x061f78aaL)) + + (t8 = mad_f_mul((t17 = X[7] + X[16]), -0x0ec835e8L)); + + x[7] = t0 + + mad_f_mul((t10 = X[0] - X[11] - X[12]), 0x0216a2a2L) + + mad_f_mul((t11 = X[2] - X[9] - X[14]), 0x09bd7ca0L) + + mad_f_mul((t12 = X[3] - X[8] - X[15]), -0x0cb19346L) + + mad_f_mul((t13 = X[5] - X[6] - X[17]), -0x0fdcf549L); + x[10] = -x[7]; + + x[19] = x[34] = -t6 + -t7 + -t8 + + mad_f_mul(t10, -0x0cb19346L) + + mad_f_mul(t11, 0x0fdcf549L) + + mad_f_mul(t12, 0x0216a2a2L) + + mad_f_mul(t13, -0x09bd7ca0L); + + t14 = X[0] - X[3] + X[8] - X[11] - X[12] + X[15]; + t15 = X[2] + X[5] - X[6] - X[9] - X[14] - X[17]; + + x[22] = x[31] = t0 + + mad_f_mul(t14, -0x0ec835e8L) + + mad_f_mul(t15, 0x061f78aaL); + + t1 = t6 + + mad_f_mul(X[1], -0x09bd7ca0L) + + mad_f_mul(X[7], 0x0216a2a2L) + + mad_f_mul(X[10], -0x0fdcf549L) + + mad_f_mul(X[16], 0x0cb19346L); + + MLA( + x[6] , t1, + MLA_STEP(X[0], 0x03768962L) + MLA_STEP(X[2], 0x0e313245L) + MLA_STEP(X[3], -0x0ffc19fdL) + MLA_STEP(X[5], -0x0acf37adL) + MLA_STEP(X[6], 0x04cfb0e2L) + MLA_STEP(X[8], -0x0898c779L) + MLA_STEP(X[9], 0x0d7e8807L) + MLA_STEP(X[11], 0x0f426cb5L) + MLA_STEP(X[12], -0x0bcbe352L) + MLA_STEP(X[14], 0x00b2aa3eL) + MLA_STEP(X[15], -0x07635284L) + MLA_STEP(X[17], -0x0f9ee890L) + ); + x[11] = -x[6]; + + MLA( + x[23] = x[30] , t1, + MLA_STEP(X[0], -0x0f426cb5L) + MLA_STEP(X[2], -0x00b2aa3eL) + MLA_STEP(X[3], 0x0898c779L) + MLA_STEP(X[5], 0x0f9ee890L) + MLA_STEP(X[6], 0x0acf37adL) + MLA_STEP(X[8], -0x07635284L) + MLA_STEP(X[9], -0x0e313245L) + MLA_STEP(X[11], -0x0bcbe352L) + MLA_STEP(X[12], -0x03768962L) + MLA_STEP(X[14], 0x0d7e8807L) + MLA_STEP(X[15], 0x0ffc19fdL) + MLA_STEP(X[17], 0x04cfb0e2L) + ); + + MLA( + x[18] = x[35] , -t1, + MLA_STEP(X[0], -0x0bcbe352L) + MLA_STEP(X[2], 0x0d7e8807L) + MLA_STEP(X[3], -0x07635284L) + MLA_STEP(X[5], 0x04cfb0e2L) + MLA_STEP(X[6], 0x0f9ee890L) + MLA_STEP(X[8], -0x0ffc19fdL) + MLA_STEP(X[9], -0x00b2aa3eL) + MLA_STEP(X[11], 0x03768962L) + MLA_STEP(X[12], -0x0f426cb5L) + MLA_STEP(X[14], 0x0e313245L) + MLA_STEP(X[15], 0x0898c779L) + MLA_STEP(X[17], -0x0acf37adL) + ); + + t9 = + mad_f_mul(X[4], 0x061f78aaL) + + mad_f_mul(X[13], -0x0ec835e8L); + + t2 = t9 + + mad_f_mul(X[1], -0x0cb19346L) + + mad_f_mul(X[7], 0x0fdcf549L) + + mad_f_mul(X[10], 0x0216a2a2L) + + mad_f_mul(X[16], -0x09bd7ca0L); + + MLA( + x[5] , t2, + MLA_STEP(X[0], 0x04cfb0e2L) + MLA_STEP(X[2], 0x0ffc19fdL) + MLA_STEP(X[3], -0x0d7e8807L) + MLA_STEP(X[5], 0x03768962L) + MLA_STEP(X[6], -0x0bcbe352L) + MLA_STEP(X[8], -0x0e313245L) + MLA_STEP(X[9], 0x07635284L) + MLA_STEP(X[11], -0x0acf37adL) + MLA_STEP(X[12], 0x0f9ee890L) + MLA_STEP(X[14], 0x0898c779L) + MLA_STEP(X[15], 0x00b2aa3eL) + MLA_STEP(X[17], 0x0f426cb5L) + ); + x[12] = -x[5]; + + MLA( + x[0] , t2, + MLA_STEP(X[0], 0x0acf37adL) + MLA_STEP(X[2], -0x0898c779L) + MLA_STEP(X[3], 0x0e313245L) + MLA_STEP(X[5], -0x0f426cb5L) + MLA_STEP(X[6], -0x03768962L) + MLA_STEP(X[8], 0x00b2aa3eL) + MLA_STEP(X[9], -0x0ffc19fdL) + MLA_STEP(X[11], 0x0f9ee890L) + MLA_STEP(X[12], -0x04cfb0e2L) + MLA_STEP(X[14], 0x07635284L) + MLA_STEP(X[15], 0x0d7e8807L) + MLA_STEP(X[17], -0x0bcbe352L) + ); + x[17] = -x[0]; + + MLA( + x[24] = x[29] , t2, + MLA_STEP(X[0], -0x0f9ee890L) + MLA_STEP(X[2], -0x07635284L) + MLA_STEP(X[3], -0x00b2aa3eL) + MLA_STEP(X[5], 0x0bcbe352L) + MLA_STEP(X[6], 0x0f426cb5L) + MLA_STEP(X[8], 0x0d7e8807L) + MLA_STEP(X[9], 0x0898c779L) + MLA_STEP(X[11], -0x04cfb0e2L) + MLA_STEP(X[12], -0x0acf37adL) + MLA_STEP(X[14], -0x0ffc19fdL) + MLA_STEP(X[15], -0x0e313245L) + MLA_STEP(X[17], -0x03768962L) + ); + + t3 = t9 + + mad_f_mul(X[1], -0x0216a2a2L) + + mad_f_mul(X[7], -0x09bd7ca0L) + + mad_f_mul(X[10], 0x0cb19346L) + + mad_f_mul(X[16], 0x0fdcf549L); + + MLA( + x[8] , t3, + MLA_STEP(X[0], 0x00b2aa3eL) + MLA_STEP(X[2], 0x03768962L) + MLA_STEP(X[3], -0x04cfb0e2L) + MLA_STEP(X[5], -0x07635284L) + MLA_STEP(X[6], 0x0898c779L) + MLA_STEP(X[8], 0x0acf37adL) + MLA_STEP(X[9], -0x0bcbe352L) + MLA_STEP(X[11], -0x0d7e8807L) + MLA_STEP(X[12], 0x0e313245L) + MLA_STEP(X[14], 0x0f426cb5L) + MLA_STEP(X[15], -0x0f9ee890L) + MLA_STEP(X[17], -0x0ffc19fdL) + ); + x[9] = -x[8]; + + MLA( + x[21] = x[32] , t3, + MLA_STEP(X[0], -0x0e313245L) + MLA_STEP(X[2], 0x0bcbe352L) + MLA_STEP(X[3], 0x0f9ee890L) + MLA_STEP(X[5], -0x0898c779L) + MLA_STEP(X[6], -0x0ffc19fdL) + MLA_STEP(X[8], 0x04cfb0e2L) + MLA_STEP(X[9], 0x0f426cb5L) + MLA_STEP(X[11], -0x00b2aa3eL) + MLA_STEP(X[12], -0x0d7e8807L) + MLA_STEP(X[14], -0x03768962L) + MLA_STEP(X[15], 0x0acf37adL) + MLA_STEP(X[17], 0x07635284L) + ); + + MLA( + x[20] = x[33] , -t3, + MLA_STEP(X[0], -0x0d7e8807L) + MLA_STEP(X[2], 0x0f426cb5L) + MLA_STEP(X[3], 0x0acf37adL) + MLA_STEP(X[5], -0x0ffc19fdL) + MLA_STEP(X[6], -0x07635284L) + MLA_STEP(X[8], 0x0f9ee890L) + MLA_STEP(X[9], 0x03768962L) + MLA_STEP(X[11], -0x0e313245L) + MLA_STEP(X[12], 0x00b2aa3eL) + MLA_STEP(X[14], 0x0bcbe352L) + MLA_STEP(X[15], -0x04cfb0e2L) + MLA_STEP(X[17], -0x0898c779L) + ); + + t4 = -t9 + + mad_f_mul(t16, -0x0ec835e8L) + + mad_f_mul(t17, 0x061f78aaL); + + x[4] = t4 + + mad_f_mul(t14, 0x061f78aaL) + + mad_f_mul(t15, 0x0ec835e8L); + x[13] = -x[4]; + + x[1] = t4 + + mad_f_mul(t10, 0x09bd7ca0L) + + mad_f_mul(t11, -0x0216a2a2L) + + mad_f_mul(t12, 0x0fdcf549L) + + mad_f_mul(t13, -0x0cb19346L); + x[16] = -x[1]; + + x[25] = x[28] = t4 + + mad_f_mul(t10, -0x0fdcf549L) + + mad_f_mul(t11, -0x0cb19346L) + + mad_f_mul(t12, -0x09bd7ca0L) + + mad_f_mul(t13, -0x0216a2a2L); + + t5 = -t6 + + mad_f_mul(X[1], -0x0fdcf549L) + + mad_f_mul(X[7], -0x0cb19346L) + + mad_f_mul(X[10], -0x09bd7ca0L) + + mad_f_mul(X[16], -0x0216a2a2L); + + MLA( + x[2] , t5, + MLA_STEP(X[0], 0x0898c779L) + MLA_STEP(X[2], 0x04cfb0e2L) + MLA_STEP(X[3], 0x0bcbe352L) + MLA_STEP(X[5], 0x00b2aa3eL) + MLA_STEP(X[6], 0x0e313245L) + MLA_STEP(X[8], -0x03768962L) + MLA_STEP(X[9], 0x0f9ee890L) + MLA_STEP(X[11], -0x07635284L) + MLA_STEP(X[12], 0x0ffc19fdL) + MLA_STEP(X[14], -0x0acf37adL) + MLA_STEP(X[15], 0x0f426cb5L) + MLA_STEP(X[17], -0x0d7e8807L) + ); + x[15] = -x[2]; + + MLA( + x[3] , t5, + MLA_STEP(X[0], 0x07635284L) + MLA_STEP(X[2], 0x0acf37adL) + MLA_STEP(X[3], 0x03768962L) + MLA_STEP(X[5], 0x0d7e8807L) + MLA_STEP(X[6], -0x00b2aa3eL) + MLA_STEP(X[8], 0x0f426cb5L) + MLA_STEP(X[9], -0x04cfb0e2L) + MLA_STEP(X[11], 0x0ffc19fdL) + MLA_STEP(X[12], -0x0898c779L) + MLA_STEP(X[14], 0x0f9ee890L) + MLA_STEP(X[15], -0x0bcbe352L) + MLA_STEP(X[17], 0x0e313245L) + ); + x[14] = -x[3]; + + MLA( + x[26] = x[27] , t5, + MLA_STEP(X[0], -0x0ffc19fdL) + MLA_STEP(X[2], -0x0f9ee890L) + MLA_STEP(X[3], -0x0f426cb5L) + MLA_STEP(X[5], -0x0e313245L) + MLA_STEP(X[6], -0x0d7e8807L) + MLA_STEP(X[8], -0x0bcbe352L) + MLA_STEP(X[9], -0x0acf37adL) + MLA_STEP(X[11], -0x0898c779L) + MLA_STEP(X[12], -0x07635284L) + MLA_STEP(X[14], -0x04cfb0e2L) + MLA_STEP(X[15], -0x03768962L) + MLA_STEP(X[17], -0x00b2aa3eL) + ); +#else t6 = mad_f_mul(X[4], 0x0ec835e8L) + mad_f_mul(X[13], 0x061f78aaL); @@ -1504,6 +1792,7 @@ mad_f_mul(X[14], -0x04cfb0e2L) + mad_f_mul(X[15], -0x03768962L) + mad_f_mul(X[17], -0x00b2aa3eL); +#endif } /*

1 0

X-Mailer: USANET web-mailer (34FM.0700.15B.01)
by Ivan Mi 29 Jan '01

29 Jan '01

Hi, Thank you very much for comprehensive explanation. They help me so much. I want to use at first time minimad like a model. As far as I understand you map whole input (mp3) file to the memory and work with pointer to this memory. But the functions defined in decoder.c like send_io, receive_io, receive_io_blocking, send, receive- used "int fd" like a handle to file. My question is where you make relation between pointer to mapped mamory and handle to file? Thank you. Ivan ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

3 4

VC++ patch for MAD.
by Kalani Sanders 27 Jan '01

27 Jan '01

I hacked together some patches to MAD, so it would compile under Microsoft VC++ 6.0. In its current form, there is only a project for compiling the in_mad.dll winamp plugin. Though the library should compile by itself, I haven't tested it. MadPlay will not compile, yet. The only real issue is with huffman.c, it uses a gnu compiler extension to initialize the second struct in the unions (the PTR macro); the Microsoft compiler has no such extensions. As I'm not planning on changing the tables, I just disabled the compiling of huffman.c and replaced it with a cygwin compiled version at link time. This hasn't been tested much, so YMMV, no guarantees and so forth. :-) You can find it at http://www.theinsaneasylum.net/~ksanders/ cheers kalani sanders ksanders(a)theinsaneasylum.net --------- Isn't Disneyland a people trap operated by a mouse?

1 0

X-Mailer: USANET web-mailer (34FM.0700.15B.01)
by Ivan Mi 25 Jan '01

25 Jan '01

Hello, I started to use MAD today and I'm not fammilliar with it up to know. I create a simple project (on VC++ 6.0) and add to it MAD source and header files , BUT when I compille it - there appear message "Cannot open file map.h". There are one file map.h, but it contain strange information: "/^\/\*$/{ N s/ \* mad - /&/ t copy b next : copy g n s|^ \* \$$Id: .*$ \$$|/* \1 */|p /^ \*\/$/d b copy } /^# *include "/d : next p " I'll be very glad if you help me in this. Thank you. Ivan ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

2 1

X-Mailer: USANET web-mailer (34FM.0700.15B.01)
by Ivan Mi 25 Jan '01

25 Jan '01

Hello, I want to use MAD files in the VC ++ (Win CE) project. I start to transform *.c files today, and found many unsupported functions like open, seek atc. But the main problem is that there is used variables like "new", "private", which are the key words in C++. I'll be very glad if anybody share with me his/her experience with transformation to C++ or if show me any free sources with transformed files. Thank you. Ivan ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1

1 0

unable to compile dai.c/isr.c from lib7209 with arm-elf-gcc
by Laurent Hoss 24 Jan '01

24 Jan '01

Hi Andrew To understand our latest problem,I better tell you what we are doing ! Our project is to port and optimize an MP3 decoder to the cirrus EP7209. Now you may think,why that, this has been done a long time ago ! You're right, but our prof. didn't want as to order a chip/board from a different manufacturer because he (we) knew that it was the best one for this job :) For the MP3 decoding we chose the "MAD Decoder", a high Q, well structured & optimized fixed-point open source-decoder: <http://www.mars.org/home/rob/proj/mpeg/> I installed redhat's ecos (RTOS which also supports the EDB72xx family) and compiled the whole arm-elf toolchain (crosscompiler: cygwin/win9x -> arm). After removing some unneeded ASYNC-features from libmad/decoder.c, the libmad library (containing only MAD's MP3-decoder routines, no player) built successfully for arm. Now we still need a minimal player which reads the MP3-Stream from the EDB7209's NAND-Flash memory and sends the decoded PCM samples to the DA. That's where the problem occurs: We are not able to include dai.c (containing the DA-wandler interface) from lib7209, because it depends on isr.c (interrupt routines) which does NOT compile with arm-elf-gcc. Problems start at line 17 with a parse error at __swi(0x123456) which has someting to do with ANGEL. I do not understand much there. Couldn't find that __swi in other source files either. Also the asm-file isrshell.S, was completely misinterpreted by gnu-as. I hope there's still a possibility to build a simple player with DA output using gcc/eCos. Thank you for you help Laurent.

1 0

sound speed probelm on the assabet
by Gad Hayisraeli 24 Jan '01

24 Jan '01

hello. i compiled the madplay (0.2.12b) for the arm-assabet (sa1110) with these options: CC=arm-linux-gcc ./configure --enable-speed --disable-debugging --enable-fpm=arm --enable-aso and i've compiled it too for the intel 386 (regular compilation: ./configure --enable-speed only --disable-debugging) and i've noticed that the playing speed in the arm version is about 8% faster than the 386 version (the 386 version speed is more suitable for the song. i've checked it in winamp also). why ? is it related to the UDA1341 driver of the assabet ? how can i fix it ? (note: at the end of the playing, both versions shows exaclty the same time elapsed). Gad

1 0

Patch for mixed_block_flag
by Rob Leslie 18 Jan '01

18 Jan '01

Hi all, I recently fixed a problem related to mixed_block_flag, a rarely used Layer III option. Attached is a patch against 0.12.2b that will go in the next release. With this patch, MAD can now correctly decode the si_block.bit and he_mode.bit test streams. BTW, is anyone aware of any encoders that actually use mixed blocks? Cheers, -rob

3 2

Re: [mad-dev] autoconf problem with mad-0.12.2b (fwd)
by Rob Leslie 18 Jan '01

18 Jan '01

Hi Jason, > Did you ever see this message? It must seem like I'm ignoring you. :-) I'm not... sorry about that. >> Are there any autoconf gurus out there that can figure out why mad >> can't handle certain CFLAGS invocations properly? >> >> For example, try the following in the mad-0.12.2b source directory: >> >> $ env CFLAGS="-O1 -O2" ./configure >> >> configure will eventually crash with something like this: >> >> checking for gcc... (cached) gcc >> checking whether the C compiler (gcc 2 ) works... no >> configure: error: installation or configuration problem: C compiler cannot create executables. >> configure: error: ./configure failed for libmad >> >> Removing the first `-O1' fixes it, but this should not be necessary >> since gcc should pick up the latter. >> >> From gcc(1): >> >> "If you use multiple -O options, with or without level numbers, >> the last such option is the one that is effective." >> >> Further, this isn't a problem on several other autoconf driven >> packages I tested this with. Yes, it's a problem with the current configure script. I've rewritten the offending portions in a way that should eliminate this problem; it will be in the next release (coming very soon...) Thanks, -- Rob Leslie rob(a)mars.org

1 0

MPEG 2.5 streams, anyone?
by Rob Leslie 16 Jan '01

16 Jan '01

Hi folks, I'm adding MPEG 2.5 support to MAD, and I'm wondering if anyone has any test streams I could use to verify that it works? Thanks, -rob

1 1

IMDCT MLA patch
by Rob Leslie 03 Jan '01

03 Jan '01

FWIW, here's a patch to use the multiply/accumulate macros in the Layer III IMDCT. Dan, if you want, you can just write something in fixed.h to define these macros for the PowerPC. Cheers, -rob

2 3

Re: [mad-dev] madplay on embedded PowerPC
by Andre 28 Dec '00

28 Dec '00

--- Dan Malek <dan(a)mvista.com> wrote: > So, my idea was to modify imdct36 so the mad_f_mul + mad_f_mul .... > sequences were replaced by 64-bit multiply/accumulates, then you > just round/scale once at the end (like I would do on a DSP). This > improved the performance by about 6%, and I ended up with great > compiler generated code. For example: > > t6 = > mad_f_mul(X[4], 0x0ec835e8L) + > mad_f_mul(X[13], 0x061f78aaL); > > becomes: > > macreg = 0; > mad_f_mac(macreg, X[4], 0x0ec835e8L); > mad_f_mac(macreg, X[13], 0x061f78aaL); > t6 = mad_f_macscale(macreg); Cool. There are actually macros to support this already - I did basically the same thing for imdct_s() in the patch I posted a link to previously. It's also in the ARM assembler imdct_l() function, but for some reason hasn't made it back into the C version yet (although I'm sure was on the TODO list at one stage ??). > I guess I need to run some official bit streams, but it sounds OK. > This could certainly be the PowerPC optimization. I'll send a > patch to someone if they would like to see it. Straight to the list is good - I guess the patch won't be huge. Final say on if/when/inwhatform it gets rolled into the main code is down to Rob though. 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

2 1

Re: [mad-dev] madplay on embedded PowerPC
by Andre 28 Dec '00

28 Dec '00

--- Dan Malek <dan(a)mvista.com> wrote: > > > Well, I'm impressed........ > > I expected to do some serious profiling and assembler writing, > but all I did was configure and make. It runs on my wimply 50 MHz > embedded MPC860 PowerPC, uses about 80% of the CPU, NFS root file > system. It's an Embedded Planet board with a Crystal CS4218 codec > running Linux. I'm using mad-0.2.12b. > > Pretty nice. Now I have to find another holiday week project :-). If you are still looking for an assembler project, MAD could probably use a PowerPC assembler version of the imdct function to match the ARM version I wrote, or maybe an assembler version of the synthesis functions which I don't think anyone has had a go at yet. There is also still some C optimisation to do if you are up to the challenge :-) see Rob's TODO list. 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

3 8

Re: [mad-dev] madplay on embedded PowerPC
by Andre 27 Dec '00

27 Dec '00

--- Dan Malek <dan(a)mvista.com> wrote: > Rob Leslie wrote: > > > .... Probably > > you're using the FPM_APPROX version now, > > Yes, that is what I was using. Unfortunately, the FPM_64BIT blows > my CPU budget on the baby processor, but it is close. I can crank > up the PLL and probably get a little more with some profiling. If the PPC has a 32x32=64bit multiply instruction, then FPM_64BIT shouldn't be much slower (if at all) then FPM_APPROX. Make sure you configure with --enable-speed and --disable-debugging though. If you are still right on the limit, you might want to try some C optimisations I did a while back: ftp://ftp.mars.org/pub/mpeg/contrib/opt3-0.12.2b.patch.gz which might be a better solution than tweaking the PLL. > I'll keep you posted on any improvements I make. > > Thanks for the great starting point! Have fun :-) 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

2 1

madplay on embedded PowerPC
by Dan Malek 26 Dec '00

26 Dec '00

Well, I'm impressed........ I expected to do some serious profiling and assembler writing, but all I did was configure and make. It runs on my wimply 50 MHz embedded MPC860 PowerPC, uses about 80% of the CPU, NFS root file system. It's an Embedded Planet board with a Crystal CS4218 codec running Linux. I'm using mad-0.2.12b. Pretty nice. Now I have to find another holiday week project :-). Thanks. -- Dan -- I like MMUs because I don't have a real life.

1 0

simple question
by Gabriel Bouvigne 21 Dec '00

21 Dec '00

I was wondering where the left_err and right_err used for dithering are computed? Regards -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org personal page: gabriel.mp3-tech.org

2 1

Fwd: [mad-dev] Re: [mad-user] MAD DLL
by ROBERTJPL＠aol.com 11 Dec '00

11 Dec '00

Hello , I keep getting many e-mails to MY e-mail address that you are supposed to be getting..

1 0

Re: [mad-dev] Re: [mad-user] MAD DLL
by Kalani Sanders 11 Dec '00

11 Dec '00

That's going to take me longer. I'm having some problems getting everything in madplay to compile properly. Until then, you should be able to compile it under cygwin, I think. cheers Kalani Sanders "Clint Kennedy" <djslakor(a)hotmail.com> wrote: > Kalani, > > could you possibly build a project for compiling madplay also? I like to > listen to current builds and Rob has added no instructions for win32 > compilation! :-) > > thanks!

2 1

Re: [mad-user] MAD DLL
by Kalani Sanders 11 Dec '00

11 Dec '00

I'm putting the finishing touches on a VC++ project to compile the winamp plugin, I'll see what I can do about adding a project for just the library. cheers Kalani Sanders "FunkyMan" <FunkyMan(a)myself.com> wrote: > I wanted to use the MAD decoder in my MP3 Player, but as a matter of facts, > i wasn't able to compile it under windows :-( > > has anyone build a DLL that can be used by a windows program (a kind of > LIBMAD.DLL), or anyone made a VC++ project to compile MAD under windows ?

1 0

dithering
by Gabriel Bouvigne 28 Nov '00

28 Nov '00

I thinked again about the dithering stuff. Dithering is usefull when we normalized, mixed, or subquantized the audio. In the case of mp3, we done a subquantization. But this subquantization was not done in the time space, but in the frequency space. That's what make me think that dithering could be better used if applied in the frequency space. But of course a constant dithering factor over a granule would a totaly useless effect, as it wouldn't change over the granule duration. So I think that this should be done in the frequency space, but on time periods a lot shorter than a granule. Does anyone have any opinion about this? Do you think it makes sense? Would it be feasible? Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org

1 0

autoconf problem with mad-0.12.2b
by Jason R. Mastaler 28 Nov '00

28 Nov '00

Are there any autoconf gurus out there that can figure out why mad can't handle certain CFLAGS invocations properly? For example, try the following in the mad-0.12.2b source directory: $ env CFLAGS="-O1 -O2" ./configure configure will eventually crash with something like this: checking for gcc... (cached) gcc checking whether the C compiler (gcc 2 ) works... no configure: error: installation or configuration problem: C compiler cannot create executables. configure: error: ./configure failed for libmad Removing the first `-O1' fixes it, but this should not be necessary since gcc should pick up the latter. >From gcc(1): "If you use multiple -O options, with or without level numbers, the last such option is the one that is effective." Further, this isn't a problem on several other autoconf driven packages I tested this with. Thanks.

1 0

MAD 0.12.2b available
by Rob Leslie 20 Nov '00

20 Nov '00

For anyone who wasn't paying attention, I released 0.12.1b a few days ago, but I decided there were a few more improvements I could make before this announcement, thus 0.12.2b. Highlights of this release include: - source for a Winamp plug-in - resolved MS+I stereo issue (no more OPT_ISKLUGE) - FreeBSD sound compatibility fixes - updated Winamp extensions to the ID3 genre list - Croatian, Norwegian, and Spanish translations for madplay - new ABX testing script - libmad API changes - bug fixes In addition, this release includes several performance enhancements: - rearranged the synthesis polyphase filterbank memory vector for better locality of reference - new combination of compiler optimization flags - some miscellaneous layer3.c changes - rewrote the audio PCM packing routines These changes have resulted in a drop from 53MHz to 50MHz CPU usage requirement on my StrongARM 1100 test platform. Unfortunately this release breaks Andre's requantization optimization patch, but I've put together a revised patch that can be applied cleanly to 0.12.2b. With Andre's patch included, CPU usage further drops to 49MHz on my SA-1100. The release is available here: ftp://ftp.mars.org/pub/mpeg/ Andre's modified patch is here: ftp://ftp.mars.org/pub/mpeg/contrib/ I will update the SourceForge mirror as soon as their site behaves again. In other news, I have set up two new mailing lists. One is an announcement-only list, mad-announce, for messages like this one (new releases, news, etc.) The other is a user-oriented list, mad-user, for people to discuss MAD (and the new MAD plug-in for Winamp) from a user and music listener perspective. In the future, messages sent to mad-announce will automatically get forwarded to both mad-dev and mad-user, so it's not necessary to change your (mad-dev) subscription unless you only want to receive announcements and not other development chatter. Details for subscribing to any list are on the MAD home page: http://www.mars.org/home/rob/proj/mpeg/ Cheers, -rob P.S. Thanks to Simon Burge, Thomas Klausner and others for nominating MAD (madplay) for NetBSD's October Package of the Month!

2 2

dithering
by Gabriel Bouvigne 12 Nov '00

12 Nov '00

It seems to me that usually dithering is done in time space. In case of PCM coding, it's comprehensible as the data is represented in time space. But what about transform coders? In our case we can access to both representations, time and frequency spaces. So I've had an idea. Perhaps it's full of nonsense, perhaps it needs to be corrected, in this case I'd like to be corrected in order to learn. My idea is to use an adaptative dithering in frequency space. As in decoding we know how much bits were used in a sfb, we could perhaps use this data to adjust the amount of dithering. This way we could dither more when less bits were used, and dither less when more bits were used. Any comments about this? Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org

2 2

seeking a fixed point tutorial
by Sean 'Shaleh' Perry 10 Nov '00

10 Nov '00

I am seeking a fixed point math tutorial that does not use asm (I do not speak asm yet). Suggestions?

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev