[pulseaudio-discuss] Purpose of 8-byte buffer alignment in cpu-mix-test.c

[Tanu Kaskinen]

On Sun, 2016-11-20 at 10:28 +0100, Peter Meerwald-Stadler wrote:
> > > Do you happen to remember why the audio buffers in run_mix_test() in
> > > src/tests/cpu-mix-test.c are forced to have 8-byte alignment? I plan to
> > > replace the stack-allocated buffers with regular memblocks, and the
> > > memblock backing memory is only aligned to 4 bytes on 32-bit machines.
> > > It's possible to still have the old alignment behaviour, but that
> > > requires extra code, and if 4-byte alignment is equally fine, then I'd
> > > prefer to avoid the extra code.
> > 
> > Also, why is the alignment so carefully controlled? All tests are run
> > on a buffer that begins one sample after the 8-byte alignment boundary.
> > Is this done to catch bugs related to weird (but valid) sample
> > alignments?
> 
> probably this also constitutes a worst-case runtime-wise; I can't remember 
> really

Ok, let's assume that the purpose of the one-sample offset is to test
the worst case. That won't work reliably if the initial alignment is
random, so that would explain why the buffer is aligned to a 8-byte
boundary.

Do you think that it makes any difference on 32-bit machines whether
the buffer is aligned to 4 or 8 bytes? I would expect there to be no
difference. If there's no difference, then the alignment guarantee that
a pool-allocated memblock gives is sufficient.

> it would be nice to have explicit alignment requirements/guarantees on 
> buffers that are potentially processed by SIMDy code; alignment might make 
> the code run faster

I think pretty much all audio buffers are aligned to the pointer size.
Do you think there would be room for improvement?

-- 
Tanu

https://www.patreon.com/tanuk