The previous value couldn't actually be expressed as a float and got rounded up
to the next whole number value, leaving the potential for an overrun in the
squared sum.
Though it didn't strictly clash since it was for a different component (global
state vs source property), 0x1213 was used by AL_RESAMPLER_NAME_SOFT. Probably
best to avoid duplicate property values regardless.
A bit of a misnomer now since "Nearest" implies rounding (i.e. when the sample
offset is >= .5, it should pick the next sample being closer in time), but that
adds unnecessary complications.
This is a bit more efficient than calling the normal HRTF mixing function
twice, and helps solve the problem of the values generated from convolution not
being consistent with the new HRIR.
Some data sets are just too sparse, having noticeably few measurements to
properly handle slowly panning sources. Although not perfect, bilinearly
interpolating the HRIR measurements improves the positional accuracy.
This greatly improves HRTF performance since the dual-mix only applies to the
64-sample coefficient transition. So rather than doubling the full mix, it only
doubles 64 samples out of the full mix.
This reduces the output volume when the mixed samples extend outside of -1,+1,
to prevent excessive clipping. It can reduce the volume by -80dB in 50ms, and
increase it by +80dB in 1s (it will not go below -80dB or above 0dB).
This update modifies the reverb in numerous ways. The 3-series, 4-parallel
all-pass is replaced with a Gerzon vector all-pass. The vector all-pass is also
applied to the early reflections, to help with the initial diffusion in the
late reverb. The late reverb filter and feedback attenuation has been replaced
with a dual first-order equalization filter, which controls the low and high
frequencies with individual low-pass/high-shelf and high-pass/low-shelf filters
with gain control.
Additionally, delay lines now have the ability to blend the output between two
offsets, to help smooth out the transition for when the delay changes (without
such, it could result in undesirable clicks and pops).
Clang does not allow using C11's atomic_load on const _Atomic variables.
Previously it just disabled use of C11 atomics if atomic_load didn't work on a
const _Atomic variable, but I think I'd prefer to have Clang use C11 atomics
for the added features (more explicit memory ordering) even if it means a few
instances of breaking const.