They are still there for auxiliary sends. However, they should go away soon
enough too, and then we won't have to mess around with calculating extra
"predictive" samples in the mixer.
This fades the dry mixing gains using a logarithmic curve, which should produce
a smoother transition than a linear one. It functions similarly to a linear
fade except that
step = (target - current) / numsteps;
...
gain += step;
becomes
step = powf(target / current, 1.0f / numsteps);
...
gain *= step;
where 'target' and 'current' are clamped to a lower bound that is greater than
0 (which makes no sense on a logarithmic scale).
Consequently, the non-HRTF direct mixers do not do not feed into the click
removal and pending click buffers, as this per-sample fading would do an
adequate job of stopping clicks and pops caused by extreme gain changes. These
buffers should be removed shortly.
The purpose of this is to provide a safe way to be able to "swap" resources
used by the mixer from other threads without the need to block the mixer, as
well as a way to track when mixes have occurred. The idea is two-fold:
It provides a way to safely swap resources. If the mixer were to (atomically)
get a reference to an object to access it from, another thread would be able
allocate and prepare a new object then swap the reference to it with the stored
one. The other thread would then be able to wait until (count&1) is clear,
indicating the mixer is not running, before safely freeing the old object for
the mixer to use the new one.
It also provides a way to tell if the mixer has run. With this, a thread would
be able to read multiple values, which could be altered by the mixer, without
requiring a mixer lock. Comparing the before and after counts for inequality
would signify if the mixer has (started to) run, indicating the values may be
out of sync and should try getting them again. Of course, it will still need
something like a RWLock to ensure another (non-mixer) thread doesn't try to
write to the values at the same time.
Note that because of the possibility of overflow, the counter is not reliable
as an absolute count.
Now instead of specifying the arguments as a third argument to the macro, like
VCALL(object,function,(arg1, arg2));
they are specified separately after the macro, like
VCALL(object,function)(arg1, arg2);
Also, VCALL_NOARGS has been removed in favor of VCALL0, which behaves like
above but expects an empty argument list (a separate macro is needed to work
around preprocessor limitations).
Unlike the device, input buffers are accessed based on channel numbers
instead of enums. This means the maximum number of channels they hold
depends on the number of channels any one format can have, rather than
the total number of recognized channels. Currently, this is 8 for 7.1.
This means the combination of the buffer frequency, source pitch, and
doppler shift can't exceed 10x the device playback frequency.
This is needed to keep the mixer from starving with a really high
increment, causing small DstBufferSize values that require a lot of
iterations.
32-bit floats can only reach between -16777215...+16777215 (25 bits) before it
starts losing whole-number accuracy. Some compiler optimizations may break
trying to multiply a float by 2147483647.0 when the result is given right to a
float parameter, causing it instead to multiply by the nearest representable
float value, 2147483648.0.
PulseAudio causes an assert if being relocked inside a callback on the worker
thread, where aluHandleDisconnect is called. We can assume it's already locked
there, so just make sure the device is locked before being calling it.
