This allows growing the array atomically with the mixer since the ALvoice
objects themselves don't move, and a new larger array of them can be swapped in
without blocking the mixer.
This update removes the 16/24-bit sample type enum, now always being 24-bit
(other than a very small size saving, there's no practical benefit to storing
16-bit samples). This also reverses the field storage, so no on-load fixup is
needed, and stores the IR delays with 2 bits of sub-sample precision, allowing
for slightly better timing (after resampling, blending, etc).
The SIMD mixers may use a few more elements beyond the irSize, so not limiting
the blend to that size can slightly improve the quality for resampled HRIRs.
The callback apparently can't be set after activation, but we can't allocate
the ring buffer until after activation when the callback is already getting
called. An ugly flag it is, then, I guess.
It seems the JACK server can send buffer size change events during device reset
and wait on it, which causes a failure since the change event can't be
processed during a reset. It's otherwise impossible to safely disable the
change event callback during a reset since the lock is already held and the
callback can be waiting to acquire it. The only guarantee we seem to have is
the event callback won't be invoked after jack_activate succeeds.
So instead, the buffer size can be queried after jack_activate and the ring
buffer allocated then, instead of using an event callback. This does mean the
buffer size can change with a start() call, but it's better than a failure to
start.
If any are left open at process shutdown, it may try to clean them up, and
subsequently close the device. This is dangerous to do at process exit, so
don't. The app should have closed the device(s) prior to exiting anyway
