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.
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.
Stopping Oboe capture drops uncaptured samples, whereas OpenAL keeps them. Also
make sure the reported available count doesn't go backwards without reading.
Use unique_ptrs for a few more types to avoid explicit free calls.
Move ThreadMainloop::wait to the unique_lock wrapper that's holding the lock.
Since the mainloop acts as both a lock and condition_variable, passing the lock
to the wait method makes no sense. Also have it optionally take a predicate
functor to dictate when to stop waiting.
This isn't great since it can fail when PipeWire is handling audio but no
devices are available at initialization, causing the Pulseaudio or ALSA backend
to be selected instead. Future versions of PipeWire are expected to have a
better way to detect if it's handling audio, but for now this is better than
nothing.
A config option is available for users to have the PipeWire backend be usable
even with no devices at initialization, just in case.
As useful as it may sometimes be to see what's being provided, at least under
kwin_wayland a not-insignificant number of video-related nodes and metadata
properties are sent through normal use of the system (most notably when
hovering over the taskbar to see window thumbnails).
