There's apparently no way to get the containing class/struct type from a static
member function, and operator new/delete are implicitly static member functions
so the macros to define them need to be told the type to allocate for. This
ensures the type specified matches the containing type.
We want to resample before minimum phase reconstruction since that changes the
phase relationship of the sampled signal, introducing a slight bit of noise
from truncated sampling. It's not clear that the frequency domain resampling
method is accurate, so resampling prior to frequency analysis is an alternative
to ensure the resulting frequencies are given the proper phase for sampling.
This also cleans up some micro allocations in loops.
Currently it makes the pkg-config file unusable as prefix is specified twice.
FULL variables do the necessary parsing and automatically prepend the prefix if needed.
Newer versions of PipeWire may add things to public structures. For example,
pw_buffer::requested added in 0.3.49. Building against 0.3.49 or newer, but
then running with 0.3.48 could result in invalid accesses since the returned
pw_buffer objects are shorter than the definition says to expect, creating
undefined behavior. Even if explicit access to the additional fields is
protected by a runtime check, the language allows the compiler to assume a
pointer to a pw_buffer object contains a complete pw_buffer, allowing the
optimizer to access the field earlier than the check (with the check only
controlling if the value gets used).
Another example is pw_time, which had a few fields added in 0.3.50 along with a
function, pw_stream_get_time_n, that provides the size of the pw_time struct
the application is using (so the library knows what version of the struct it
has to fill in). If a later version adds a new field, running it with an older
version will either fail (due to the library getting a size larger than it
knows about) or silently leave the newer fields as garbage.
Building against 0.3.50 or newer will require that version or newer at runtime.
Building against a version before 0.3.50 will work with newer versions.
The backend is apparently using some stuff that wasn't in earlier headers, but
it's not clear what was introduced in which versions. 0.3.23 should work,
though it may need to be higher or it could go a bit lower.
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.
