Force 16-byte buffer alignment for SIMD

[0EVSG]

Hello,

I stumbled upon this when I investigated jackd consistently crashing in some
configurations of OSS on FreeBSD. In summary, the buffer size is reset
according to the number of samples requested by the driver backend. If this
number is not a multiple of 4, jackd will misalign its buffers for SSE SIMD
instructions and die with SIGBUS when processing them. The proposed fix
introduces some padding to align the buffers, in case this happens.

Please note that even though these odd buffer sizes seem to be unusual, the
problem is not necessarily tied to the OSS backend.

More details can be found in the commit message and in the original bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234574
The proposed patch is the same as currently applied in the FreeBSD ports tree.

Thanks for your consideration

Florian Walpen

---

Commit message:
With build option USE_DYNSIMD, SSE SIMD instructions are enabled that require
16-byte aligned buffer data. Multiple buffers are allocated in one contiguous
block of memory, the buffer size is determined by the number of 4-byte float
samples (nframes) per buffer. If this number is not set to a multiple of 4, the
offset of subsequent buffers will be misaligned and jackd crashes with SIGBUS.

An example of this actually happening would be using 24 bit sample size in the
OSS backend, where the page sized system buffers may result in an odd number of
samples per buffer. See
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234574
for a detailed bug report.

This change effectively adds some padding by rounding up the allocated buffer
size to a multiple of 16 bytes, given that both:

a) SIMD instructions are enabled in the build.
b) The requested buffer size is not already a multiple of 16 bytes.

All other cases should be unaffected. The existing buffer handling, copy and
mix code seems to be well prepared for padded buffers, with the number of
samples (nframes) and buffer offsets kept separately.

[0EVSG]

Hi @falkTX and @DomT4, sorry to bother you, is anyone of you still maintaining this repo?
If not, do you know who I could contact to get some feedback on this matter?
Thanks a lot!

[falkTX]

I am maintaining this repo.
Currently busy with other things, I am giving more time for stuff to accumulate on JACK to then do all at once.

Your patch makes sense.
The same issue happens on JACK2, which I have experienced it myself.

[0EVSG]

Ok, good to know - no hurry from my side either.