mingw-w64 has added this from Proton (which added this from SDL), so we need to re-define it as a local symbol to avoid conflicting with mingw-w64 headers.
Fixes https://github.com/libsdl-org/SDL/issues/9031
This means the allocator's caller doesn't need to use SDL_OutOfMemory directly
if the allocation fails.
This applies to the usual allocators: SDL_malloc, SDL_calloc, SDL_realloc
(all of these regardless of if the app supplied a custom allocator or we're
using system malloc() or an internal copy of dlmalloc under the hood),
SDL_aligned_alloc, SDL_small_alloc, SDL_strdup, SDL_asprintf, SDL_wcsdup...
probably others. If it returns something you can pass to SDL_free, it should
work.
The caller might still need to use SDL_OutOfMemory if something that wasn't
SDL allocated the memory: operator new in C++ code, Objective-C's alloc
message, win32 GlobalAlloc, etc.
Fixes#8642.
The device ID strings don't change between connects, so we need to move the
old device object out of the way if it still exists as a zombie, and let
the reconnected device get itself a fresh object.
This does a ton of work that can deadlock, because several crucial WASAPI
things that we want to do in response to this will block until the
notification callback has returned, so we can't call them from the handler
directly, or we'll be waiting until the thing that called us returns.
This does an enormous amount of work in SDL_immdevice.c to simplify and
clean up that interface, while moving some of its responsibilities to the
higher level SDL_audio.c. I hope I saw the whole picture here, and this
wasn't foolhardy of me.
WASAPI has not been updated for these changes, or for SDL3 at all, yet. As
such, it continues to be broken for now. It will be updated soon.
This code compiles with my cross compiler, but hasn't been built with
Visual Studio, or tested in any form, so there might be obvious fixes
following along shortly.
They can vanish for UP TO EIGHT SECONDS...!
This is for devices that connect to HDMI/DisplayPort/etc, where it
presumably has to wait for a display to get up and running before it
can play audio through it, so one can see the audio device fail when
changing display modes, or the system returning from sleep. Since this
can be triggered by a game changing video resolutions at startup (either
before or after opening the audio device!), it's important to deal with.
In normal conditions, it shouldn't take this long to open or recover an
audio device, but this is better than unexpectedly losing the device
in this situation.
Fixes#7044.
Fixes#5571.
(cherry picked from commit 48e71ae87b)
