This used to do different things for recording streams in different parts of
the codebase, not to mention two separate codepaths through
UpdateAudioStreamFormatsPhysical in any case. My hope is this should kill off
a few corner case bugs...for example, this one:
Fixes#8402.
This could happen if you call SDL_BindAudioStreams() when the subsystem isn't
initialized, and possibly in other corner cases.
Thanks to Qianxin CodeSafe Team, @QiAnXinCodeSafe, for discovering this issue!
Fixes#11643.
Sometimes these callbacks will fire while we're still waiting on state to
settle down in PIPEWIRE_OpenDevice, which means we're holding the device lock,
but then the i/o callback will fire from a background thread and also try to
grab the device lock, but can't, because PIPEWIRE_OpenDevice is holding it and
waiting for this i/o callback to finish...hence, a deadlock.
So now, if the device is still opening, output callbacks will write silence
and input callbacks will just flush the buffer, without calling the main
iterate function, and thus avoid obtaining the lock.
This includes both wasm64 and wasm32 when addressing more than 2gb of memory.
Fixes: #9052
(Manually cherry-picked from 3deb07ea395373204462130c1e062bc1f71fe060.)
We require stdbool.h in the build environment, so we might as well use the plain bool type.
If your environment doesn't have stdbool.h, this simple replacement will suffice:
typedef signed char bool;
We always need to destroy the hotplug loop and its associated resources
(if created) before we can deinitialize and unload the Pipewire library.
In the happy path where everything worked correctly, this means we will
call hotplug_loop_destroy() twice (once from PIPEWIRE_DeinitializeStart()
and a second time from PIPEWIRE_Deinitialize()), but that's OK, because
it's idempotent and so will do nothing the second time.
In error-handling code paths, this avoids needing to remember to call
hotplug_loop_destroy() explicitly, which should make it easier to avoid
bugs like #10787.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Also marked the existing functions as unsafe, as they can cause crashes if used in multi-threaded applications.
As a bonus, since the new functions are hashtable based, hint environment lookups are much faster.
This used a tiny stack, which apparently upsets Blender for various
technical reasons. Instead, just use the default stack size, which should
give it plenty of space to work.
If the thread failed to create, we would then wait on a semaphore that would
never trigger, so don't do that anymore!
Fixes#10806.
@smcv may have found the root cause of the pipewire thread crash, so removing the pipewire client version check to re-enable use of pipewire in older container runtimes.
