The AAudio driver implemented pause/resume by dangerously locking the audio devices. If there was an audio hotplug event or a background thread tried to interact with the audio system, this could cause deadlocks.
Removed duplicate hints SDL_HINT_APP_NAME, SDL_HINT_APP_ID, and
SDL_HINT_AUDIO_DEVICE_APP_NAME.
Wired up a few things to use the metadata; more to come!
Fixes https://github.com/libsdl-org/SDL/issues/4703
It was intended to make the API easier to use, but various automatic garbage collection all had flaws, and making the application periodically clean up temporary memory added cognitive load to using the API, and in many cases was it was difficult to restructure threaded code to handle this.
So, we're largely going back to the original system, where the API returns allocated results and you free them.
In addition, to solve the problems we originally wanted temporary memory for:
* Short strings with a finite count, like device names, get stored in a per-thread string pool.
* Events continue to use temporary memory internally, which is cleaned up on the next event processing cycle.
The preferred Pipewire path requires both devices being available, and that a sufficiently recent underlying core version is running on the host system. These criteria were being checked separately, which required two separate instances of enumerating the Pipewire registry, which is a fairly heavy operation. Move the version info callback to the main hotplug thread to avoid enumerating the registry twice, and check for both the version and required devices at the same time on the preferred path.
I _did_ appreciate the explanation, but it doesn't have to live in the
source code; also we can just release `devuid` and then check for error with
the usual macro, since SDL is done with it either way at this point.
This declares that any `const char *` returned from SDL is owned by SDL, and
promises to be valid _at least_ until the next time the event queue runs, or
SDL_Quit() is called, even if the thing that owns the string gets destroyed
or changed before then.
This is noted in the headers as "the SDL_GetStringRule", so this will both be
greppable to find a detailed explaination in docs/README-strings.md and
wikiheaders will automatically turn it into a link we can point at the
appropriate documentation.
Fixes#9902.
(and several FIXMEs, both known and yet-undocumented.)
We're seeing people with legit PipeWire installs that don't export any
devices, that are also running a (not emulated) PulseAudio install that
works.
This solution might still get tweaked some more, but it seems to be working
so far.
During playback, don't queue another buffer unless there are none in the queue.
During capture, there may be multiple buffers of audio available.
WASAPI_CaptureFromDevice only processes one buffer, and if we always wait on the next event, we will never catch up if it falls behind.
When running in a container, the underlying Pipewire version may not match the library version, so retrieve and check the core version info to see if it meets the preferred version requirements.
Checking for the pipewire-pulse service is unreliable when used in containers such as Flatpak, so simply use a minimum version check instead and prefer it over the Pulseaudio backend if at least version 1.0.0.
