When the flushing is not able to keep up with the audio stream coming in, it
will end up flushing forever and block API clients from getting any audio.
The example program in #9706 get some audio with SDL 3, while do not get any
audio with SDL 2, which I suspect is because SDL 3 is quicker at flushing the audio.
A fix for the SDL 2 issue is available in #12378.
If the pipewire thread invokes output_callback() while we're still
waiting inside PIPEWIRE_OpenDevice(), we will deadlock. The pipewire
thread owns the loop lock and is blocked on the audio device lock,
which cannot be released because pw_thread_loop_wait() needs to
reacquire the loop lock before it can return and allow
PIPEWIRE_OpenDevice() to complete and release the device lock.
This was intended to make the API public, so SDL_hashtable.h got an extreme
documentation makeover, but for now this remains a private header.
This makes several significant interface changes to SDL_HashTable, and
improves code that makes use of it in various ways.
- The ability to make "stackable" tables is removed. Apparently this still
worked with the current implementation, but I could see a future
implementation struggle mightily to support this. It'll be better for
something external to build on top of the table if it needs it, inserting a
linked list of stacked items as the hash values and managing them separately.
There was only one place in SDL using this, unnecessarily, and that has also
been cleaned up to not need it.
- You no longer specify "buckets" when creating a table, but rather an
estimated number of items the table is meant to hold. The bucket count was
crucial to our classic hashtable implementation, but meant less once we
moved to an Open Addressing implementation anyhow, since the bucket count
isn't static (and they aren't really "buckets" anymore either). Now you
can just report how many items you think the hash will hold and SDL will
allocate a reasonable default for you...or 0 to not guess, and SDL will
start small and grow as necessary, which is often the correct thing to do.
- There's no more SDL_IterateHashTableKey because there's no more "stackable"
hash tables.
- SDL_IterateHashTable() now uses a callback, which matches other parts of SDL,
and also lets us hold the read-lock for the entire iteration and get rid of
the goofy iterator state variable.
- SDL_InsertIntoHashTable() now lets you specify whether to replace existing
keys or fail if the key already exists.
- Callbacks now use SDL conventions (userdata as the first param).
- Other naming convention fixes.
I discovered we use a lot of hash tables in SDL3 internally. :) So the bulk
of this work is fixing up that code to use the new interfaces, and simplifying
things (like checking for an item to remove it if it already exists before
inserting a replacement...just do the insert atomically, it'll do all that
for you!).
The comment in the source wasn't true; PipeWire doesn't _have_ to work in
float format. It presumably does if it has to mix, but if a game is the only
thing making noise on the system--a common scenario--then it might be able to
pass, say, Sint16 data straight through to the hardware without conversion.
Fixes#12129.
You can end up with a NULL scratch buffer, which is otherwise not needed on
this path, then ConvertAudio will end up needing that scratch space to move
to float32 to apply gain.
Fixes#12091.
(I assume.)
Audio streams used to accept audio with a src or dest frequency between
4000Hz and 384000Hz. It was arbitrary (or perhaps a relic of older
resampler revisions), and testing shows unnecessary, so remove it.
Fixes#12098.
This doesn't affect latency much, but it makes the system usable if the system
drops you down from the bluetooth a2dp profile (headphones) to the handsfree
(I think...?) profile because the bluetooth audio device is also recording,
which would be extremely common in a VoIP app, but also if you're talking
in a different app while also playing audio.
Fixes#8192.
We require at least Xcode 12.2 and macOS SDK 11 to build. We support deploying to macOS 10.13, iOS 11.0, and tvOS 11.0.
This cleans up the code significantly
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.
Brick
Petter Reinholdtsen
Cameron Gutman
Petar Popovic
Sam Clegg
Ryan C. Gordon
Frank Praznik
Neal Gompa
hspir404
nightmareci
Sam Lantinga
Carl Åstholm
L zard