Hello Fabian, Am 02.06.2015 um 12:11 schrieb Fabian Greffrath: > but that shouldn't make a difference, because the code already worked > correctly when you forced it to 16-bit boundaries by using > posix_memalign().
I just wanted to have a less invasive change. > What happens if you re-arrange the definition of the vecfloat_union so > that _m128 is its first member, i.e. > > typedef union { > __m128 _m128; > int32_t _i_32[4]; /* unions are initialized by its first member */ > float _float[4]; > } vecfloat_union; > > This is how these unions are used in most examples that I found. With _m128 being the first line the crash still happens with or without the attribute. > Also, do you have any idea what this comment in there wants to tell us? I guess this is a hint for this initialization: - const vecfloat_union fabs_mask = {{ 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF }}; This could be probably more explicit (but less portable) by doing something like this: + const vecfloat_union fabs_mask = { ._i_32 = { 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF, 0x7FFFFFFF } }; With this, reordering the members of the union does not affect audio output. > You could even drop the _i_32[] member, it is not used in the code. > Maybe the compiler recognized that and somehow optimized that out, > messing the alignment thereby? Removing _i_32 seems to initialize the union differently and therefore the result is different. With _i_32 removed (and the alignment 0x20) audio is not working anymore. Kind regards, Bernhard _______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers