Similar to the previous, but includes the top and bottom HRTF responses. The
higher-order decode (for the "basic" HRTF output) also now uses 2H1P mixed-
order instead of 2H1V, which seems more stable.
Still unsure how to handle reverb modulation without some kind of reference
output, so remove the related functions to not waste CPU time. It'll remain in
the Git history should it ever need to be resurrected.
The delay scale is roughly linear with respect to room size, however the
density is not linear with room size. The density is calculated by taking the
room size cubed, then normalized by some factor. Unnormalizing the density and
taking the cube root restores the original room size to use as a delay scale.
The patch also alters the delay and all-pass line lengths to be based on a 1
meter room size, so the the room size recovered from the density acts as a
direct multiple for the desired target length.
Note that the room scale range is unchanged (5m to 50m), so the minimum and
maximum delays are the same. It should also be noted that 50m may not be the
correct room size for a density value of 1. A density value of 1 corresponds to
an environment size of roughly 2.52m when converted from EAX (DENSITY_SCALE
should be 16 rather than 125000), but sizes that low result in undesirable
resonance in the feedback, indicating other changes are necessary for that to
work.
They're inherently protected by the mutex for their respective lists. Should
those mutexes be replaced by rwlocks the individual locks should also be
reinstated, but they're unlikely to be unless a lot of contention starts
happening in the read-only case.
Semaphores allow for semi-persistent signals, compared to a condition variable
which requires a mutex for proper detection. A semaphore can be 'post'ed after
writing some data on one thread, and another thread will be able to recognize
it quickly even if the post occured in between checking for data and waiting.
This more correctly fixes a race condition with events since the mixer
shouldn't be using mutexes, and arbitrary wake-ups just to make sure an event
wasn't missed was quite inefficient.
To avoid having unknown user code running in the mixer thread that could
significantly delay the mixed output, a lockless ringbuffer is used for the
mixer to provide events that a secondary thread will pop off and process.
