With the increased use of PipeWire, which offers JACK compatibility, the JACK
backend has a higher potential to be auto-selected for users. However, due to
the backend's inability to auto-configure output to the device format, this
creates a less optimal out-of-the-box experience.
Unfortunately this also means the JACK backend won't be used automatically when
a real JACK server is running along with PulseAudio. While not ideal, this is
probably the better of the two options, to have the user explicitly configure
the library to use JACK when they really want to use it, instead of unwantingly
selecting JACK because of PipeWire.
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.
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
