mad-dev January 2001

mad-dev@lists.mars.org

10 participants
12 discussions

mad performance question
by Gad Hayisraeli 19 Feb '01

19 Feb '01

i'm trying to get the best from madplay (0.2.12b), and my goal is to jump to certain milisecond in the song, when i get an interrupt (keyboard). i use mad_stream_skip within mad_header_dcode() to acheve this. while monitoring the latency between getting the interrupt and having the jump done, i noticed that both in assabet and intel PIII i acheve latency of between 2-50 miliseconds. by saying latency, i mean that while i wanted to jump to X position, i jumped de-facto to X+20ms, for example. can i make it better ? (i want to acheve <10ms or fixed latency up to 40ms) maybe my measure isnt right ? ( i take stream->current_frame time after the skip, when i get into mad_header_decode(), and the latency calculated by: latency=desired time-current time. maybe current time isnt calculated exctly ? mabe i need to use real-time linux kernel ? Gad

4 9

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

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 January 2001