If setting the requested format channel count fails, getting anything with 2 or
more channels assumes the first two channels are stereo, leaving the rest
silent.
This way merely avoids the several lines of spam when the config module isn't
found, which there's otherwise no reasonable way to test for since they're
provided by the package, which you need to use find_package to search for,
which causes the spam. It's still useful to report the packages weren't found
in case they were expected.
* Make OpenALConfig.cmake compatible with CMake's FindOpenAL.cmake
* Create and install OpenALConfigVersion.cmake
* cmake: drop creating of OpenALConfigVersion.cmake
The itu5.1-nocenter preset is the same as the previous default, so it can still
be used for people that prefer it. But this new one purportedly has better
panning and positioning responses in listening tests, which initial impressions
concur with.
It's inconsistent behavior with spatialized B-Format sources, and causes a very
apparent gain disparity between such a source on the listener compared to just
barely off-origin. It's also not something an app can easy correct for if it
doesn't want that behavior, since the source gain clamps to 1 by default. In
contrast, an app can attenuate sources as they want with little issue.
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.
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's too unstable with larger vectors. Even when the source and listener
positions are the same, floating point precision can cause noticeable rounding
errors.
