This change affects cases where a sound is loaded while the same sound
is still in the process of being decoded. It makes it so the ASYNC flag
will only wait for the underlying data buffer to be initialized,
whereas the lack of ASYNC flag will result in it waiting for the entire
sound to be fully decoded.
This crackling was happening due to abrupt volume transitions as the
gain changes for each channel as sounds move around the world. This
change smooths out these transitions using linear interpolation.
* Sounds can now have another node be used as input rather than a
data source.
* Sounds can now have a configurable input and output channel count.
For sounds that are backed by a data source, the input channel
count will always be set to the data source's native channel count.
* Sounds can now be initially attached to any node and input bus
rather than only a sound group.
With this change, sounds can now be used as groups. In future commits,
it's likely that ma_sound_group will be unified with ma_sound. Whether
or not the `ma_sound_group_*()` APIs will continue to exists is for now
undecided.
This change allows more flexibility for doing custom effects before the
spatialization stage in the DSP pipeline. The problem with the existing
design is that there's no way to apply a custom effect before
spatialization which becomes a problem because spatialization will
often increase the channel count which results in excessive effect
processing due to the increased channel count. Now it should be
possible to set up a graph such that an effect can be plugged in
between the data source and the spatializer.
A new function called `ma_sound_init_ex()` has been added which is what
needs to be used to initialize a sound without a data source. This API
uses the config/init pattern. The config is called `ma_sound_config`.
When the listener is looking at exactly the same direction as the world
up vector the 3D math breaks down due to a cross product evaluating to
a zero length vector.
The range of the value isn't obvious to any compiler, as it could go for
one iteration or 4 billion iterations. Adding MA_ASSUME in these places
helps the compiler understand the range of possible values, and know how
heavily to vectorize (or not vectorize) these loops.
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
These values are constant, but Clang has some trouble noticing that,
especially if the loop body is complex enough. This prevents it from
noticing places where vectorization is possible (and desirable).
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
David Reid
Steven Noonan