This would happen when you had ~1 frame of audio left in the stream, and
resampling needs would cause this to not be enough to produce audio.
But since we're already flushed, we can just add silence padding to let the
app extract these last bits.
Before it would just block in read operations, but separating this out
matches what output devices already do, and also lets us separate out the
unlocked waiting part from the fast part that holds the device lock.
This means "I don't care what format I get at all" and will just use
the device's current (and/or default) format.
This can be useful, since audio streams cover the differences anyhow.
If we wait for context subscription to finish, we might miss the signal
telling us to terminate the thread...this can happen if an app initializes
the audio subsystem and then quits immediately.
So just go right into the main loop of the thread; the subscription will
finish when it finishes and then events will flow.
Zombie devices just sit there doing nothing until a new default device
is chosen, and then they migrate all their logical devices before being
destroyed.
This lets the system deal with the likely outcome of a USB headset being
the default audio device, and when its cable is yanked out, the backend
will likely announce this _before_ it chooses a new default (or, perhaps,
the only device in the system got yanked out and there _isn't_ a new
default to be had until the user plugs the cable back in).
This lets the audio device hold on without disturbing the app until it can
seamlessly migrate audio, and it also means the backend does not have to
be careful in how it announces device events, since SDL will manage the
time between a device loss and its replacement.
Note that this _only_ applies to things opened as the default device
(SDL_AUDIO_DEVICE_DEFAULT_OUTPUT, etc). If those USB headphones are the
default, and one SDL_OpenAudioDevice() call asked for them specifically and
the other just said "give me the system default," the explicitly requested
open will get a device-lost notification immediately. The other open will
live on as a zombie until it can migrate to the new default.
This drops the complexity of the PulseAudio hotplug thread dramatically,
back to what it was previously, since it no longer needs to fight against
Pulse's asychronous nature, but just report device disconnects and new
default choices as they arrive.
loopwave has been updated to not check for device removals anymore; since
it opens the default device, this is now managed for it; it no longer
needs to close and reopen a device, and as far as it knows, the device
is never lost in the first place.
These files are completely different from SDL2, and no clean merging
is likely to happen there anyhow, so there's really no harm in just
switching them over completely to SDL3's new policy of allowing `//`
comments and mixed variable declarations.
Feels deeply sacrilegious, though.
Now you open an audio device and attach streams, as planned, but each
open generates a new logical device. Each logical device has its own
streams that are managed as a group, but all streams on all logical
devices are mixed into a single buffer for a single OS-level open of
the physical device.
This allows multiple opens of a device that won't interfere with each
other and also clean up just what the opener assigned to their logical
device, so all their streams will go away on close but other opens will
continue to mix as they were.
More or less, this makes things work as expected at the app level, but
also gives them the power to group audio streams, and (once added) pause
them all at once, etc.
I don't think this can fail at the moment, but if WaveCheckFormat goes
out of sync with this switch statement at some point, this seems like
a good failsafe.
Ryan C. Gordon