alignment bug in liba52/resample_altivec.c

[ivan.middleton@…]

The AltiVec load and store instructions require addresses to be 16-byte aligned
(the low 4 bits of the address are ignored). Since the code in
liba52/resample_altivec.c doesn't account for this, some very noticeable clicks
get introduced into the audio stream.

[ivan.middleton@…]

3-second AVI for testing altivec alignment bug

[ivan.middleton@…]

The following commandline should exhibit the bug on a system with altivec:

mencoder -speed 0.95 -srate 48000 -af lavcresample=48000 -ovc copy -oac lavc
-lavcopts acodec=ac3:abitrate=128 3sec.avi -o clicks.avi

[ivan.middleton@…]

I should note that in most cases, the pointers passed to
a52_resample_STEREO_to_2_altivec are in fact 16-byte aligned.

The float pointer seems to always be aligned because of the memalign call in
a52_init (liba52/parse.c).

The int16 pointer s16 is sometimes not aligned-- the test case I've provided
seems to be exceptional because of the speed change.

It looks like it would be necessary to make sure that sh_audio->a_buffer /
sh_audio->a_buffer_len / sh_audio->a_out_buffer / sh_audio->a_out_buffer_len are
always 16-byte aligned. I can't tell whether this is feasible or not.

If that's not feasible, then the altivec code should test alignment and act
accordingly (I'm not sure what the fastest solution would be in the case of
non-alignment).

[poirierg@…]

(In reply to comment #1)

Created an attachment (id=274) [edit]
3-second AVI for testing altivec alignment bug

The following commandline should exhibit the bug on a system with altivec:

mencoder -speed 0.95 -srate 48000 -af lavcresample=48000 -ovc copy -oac lavc
-lavcopts acodec=ac3:abitrate=128 3sec.avi -o clicks.avi

Bug confirmed. I'll see what I can do. I'm afraid it's a bit too much of a corner case to have a high
priority in my list though :-(

Guillaume