The write vector represents the chunks queued for OpenSL, and the write pointer
only increments when OpenSL fills in more samples. So requeueing from the start
of the write vector is requeueing chunks that are already queued, which is
obviously wrong. It instead needs to queue chunks that become available as
they're read.
Because the ring buffer holds more elements than can be written to at a givem
time, the read vector does not represent the next writable chunks to queue.
Advancing the read pointer increases the number of writable elements, so
instead of queueing from the read vector or the start of the write vector,
queue from the end of the write vector given the number of chunks read.
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.
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.
