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
Though fine in theory, an issue arises with extra phase interference since the
frequency phases aren't aligned for each response. It would be better to do the
blending before minimum phase reconstruction, where it can blend just the
frequency magnitudes, essentially allowing makemhr to increase the resolution
of the dataset.