It's treated as 5.1 + 2 aux channels. This allows AL_DIRECT_CHANNELS_SOFT to
behave better, not forwarding rear left/right channel inputs to lower front and
upper rear, and allows reporting a more appropriate output mode to the app
instead of 7.1.
It messes with 5.1 sources using direct channels, and the surround channels are
supposed to map to the side labels. Individual backends can deal with the
channel order/label differences, as they already do to a degree.
AudioBufferList contains a variable length array of mNumberBuffers elements, so it should not be created with the default constructor like usual class instances.
Unfortunately, Apple developer site documentation is literally empty for this API. There is a bunch of comments in framework's header files.
Here is the correct usage of AudioBufferList pointer from Chromium: 008a1abc57/audio/mac/audio_manager_mac.cc (266)
There were occasional crashes because of memory corruption which was confirmed by address sanitizer
It will not be called while the device is running. If the first call succeeds,
a subsequent call that happens to fail must leave the existing device state as
it was so it can be resumed.
This is a rough first pass. It will fail when trying to re-open the same device
which can only be opened once (for instance, with direct hardware access, on
hardware that doesn't do its own mixing). Some backends won't guarantee the new
device is usable until the reset() or start() call.
The padding must be constant and sample type aligned (e.g. some fixed multiple
of two bytes between the start of two consecutive frames for 16-bit output).
The intent is to always have the ability for stereo output with WASAPI even if
the device has some other unsupported configuration, as long as front-left and
front-right exist.
