I'm having some problems with libmad running on ARM using GCC-3.2. I verified that I have the same problems with GCC-3.2.1, but I'm using GCC-3.2 for most of this. My GCC is built for armv4 architecture, I'm running on a Cirrus ARM7 part.

I've worked through the issues enough to sort out my problems, but I would like to get to the bottom of the problem if anyone has insights.

Built as released in 0.14.2b with gcc-3.2 (or gcc-3.2.1), the decoder produces odd sounding artifacts in typical layer-3 MP3 files. It sounds to me like some sort of aliases of high frequencies and lower frequencies sound fine, but I'm no expert in this sort of thing. Let's just say it sounds weird.

If I change the optimization of layer3.c from the default "-O" to "-O2" the decoder behaves correctly and nicely decodes MP3s.

To make things a little more complicated, if synth.c is changed from "-O" to "-O2", the text segment of synth.o gets quite a bit larger and the performance of the decoder degrades to the point where a 128kbps 44.1k layer3 MP3 no longer decode in real-time on a 74MHz ARM7tdmi. Bleh. With "-O2" the dct32() routine in synth.c blows up into a lot more code that I have a difficult time understanding. It seems to put a large number of loads and stores at the beginning and end of the routine that doesn't make sense to me.

Anyway, for things to work properly it seems that layer3.c needs to be "-O2" and synth.c needs to be "-O".

Okay, I've now done a little more refinement on this problem and it seems that the problems with both synth.c and layer3.c are related to the optimization option "-fschedule-insns". layer3.c must have the option -fschedule-insns (which is included by default with -O2), and synth.c must not have -fschedule-insns. So, my workaround is to change the default optimization in libmab to "-O2" and twiddle the makefile to add the option "-fno-schedule-insns" to synth.c.

If anyone has any similar experiences or ideas, please let me know.

jeff