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
