It's not available as an AL buffer format (yet) since I'm not sure how to
expose it. Internally it seems fine as a separate channel configuration, but
because OpenAL combines the channel configuration and sample type, a flag may
work better there.
There's now effectively a 16-channel limit for buffers (as determined by the
number of elements in DeviceBase::mSampleData). Any more than that are
ignored when mixing.
Rather than stopping voices/sources when the device becomes disconnected, the
context can be set to leave them alone. As a consequence, their state will
remain as playing and they'll keep their last known sample offset indefinately.
For applications mindful of this behavior, it will allow resetting or reopening
the device to reconnect and automatically resume where it left off.
The inverted atomic flag replaces test_and_set+clear with test_and_clear+set,
essentially inverting the flag status. This makes more logical sense for
flagging dirty state, which is less confusing than flagging clean state. The
one caveat is ATOMIC_FLAG_INIT (or default construction in C++20) initializes
the state to true rather than false.
This uses a bit more memory (each voice needs to hold buffers for the
deinterleaved samples of each channel, instead of just one buffer for the
current channel being mixed on the device), but it will allow for handling
formats that need or prefer their channels decoded together.
This mainly avoids having to allocate ~64-byte structures individually. The
mixing voice still holds the queue as a linked list so as to be container-
agnostic.
Used when upsampling low-order ambisonic signals to higher order. Rather than a
hardcoded 400hz, it ensures a consistent crossover point when an ambdec
configuration is used. It can also allow for an alsoft config option.