pa_channel_map_init_auto() with PA_CHANNEL_MAP_WAVEEX does the wrong
thing as it just takes the lest significant bits of
WAVEFORMATEXTENSIBLE's dwChannelMask in order. This doesn't match SDL's
chosen channel ordering.
The implementation here mirrors what we do for PipeWire.
Setting AudioCategory_GameChat breaks audio on several devices, including Behringer U-PHORIA UM2 and RODE NT-USB Mini. We'll disable this for now until we understand more about what's happening.
This is probably something we already cleaned up that has something running
in an unexpected order now that we've moved disconnect work to the main thread.
This avoids situations like:
- PulseAudio holds its own lock in the hotplug thread.
- The hotplug thread notices a device went away.
- The hotplug thread calls SDL_AudioDeviceDisconnected().
- SDL_AudioDeviceDisconnected() tries to grab the device lock.
- The device thread is holding the device lock...
- ...but is currently waiting on PulseAudio's lock to release.
In short: deadlock. It's better to queue this work to run on the main thread,
where we can guarantee a start with _none_ of the audio subsystem locks held.
snd_pcm_recover() puts the device back in SND_PCM_STATE_PREPARED state; you
have to explicitly restart the device afterwards with snd_pcm_start().
Fixes#13761.
Building SDL for armeabi-v7a gives this warning:
```
SDL/src/audio/SDL_audiotypecvt.c:541:14: warning: '#pragma FENV_ACCESS' is not supported on this target - ignored [-Wignored-pragmas]
541 | #pragma STDC FENV_ACCESS ON
```
This reverts commit 608f706a95.
Didn't end up using this in SDL3_mixer, and it's a super-awkward API if we
don't need it.
I _might_ bite the bullet and let people lock a physical audio device, though,
as I could see that being useful but less awkward for the same reasons I
originally wanted it.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
It _must_ have the format set for the opposite side from the device (so
playback needs the src format set, and recording needs the dst format set),
since the stream gets mangled by the device thread if not. So if it has never
been set (stream created with NULL audiospec), just set it to match the device.
If the stream is just meant to buffer and not convert, this is desired
behavior, even if it didn't also fix a bug.
Binding the audio stream will always set the device side's format, as usual;
this does not need to be set by the caller at all.
Fixes#13363.
This is a special-case piece of functionality, generally these are expected
to go away during shutdown, but maybe someone is switching between audio
subsystems or something...
