In particular, it relies on derived structs using C++-style inheritence. Any
implementation's source that's converted to C++ will consequently need to make
that change.
Because of early C++11 (GCC 4.x) deficiencies, it's not interpreted correctly.
Either declare the type name explicitly with uniform initization, or use auto
with = initialization. It'll be fine when updating to GCC 5 or Clang 3.6.
For playback, increment the ring buffer's write pointer before queueing audio,
to handle cases where the callback is invoked, advancing the read pointer,
before the write pointer is advanced.
For capture, limit the number of re-queued chunks to the number of fully read
chunks.
Draining the ALSA device via stopping puts it into a setup state, which
requires re-preparing before playback can start again. Preparing it prior to
the first start seems to cause no harm, so just always do it before starting.
I honestly have no idea which is the correct (or better) mode to use given the
confusing mess COM is, but CoInitialize uses single-threaded apartments which
seems to be a problem for with at least a couple games in the STALKER series
(the call fails, which causes us to drop back to the DSound backend).
It seems to actually have a negative performance impact when the system is
under load. Without having actual measurements for any potential benefits,
simply go with the recommended (and previous fallback) method of allocating
space for the write and passing the free method.
Ideally some kind of ring buffer could be used, so rather than constantly
allocating and freeing blocks of memory, it uses the same memory over again
with the callback marking each one as reusable. Unfortunately the callback
isn't given much information to work with, and the update size (minreq) can
potentially change during playback, which complicates things.
