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.
This allows using a much smaller (1.5 KB) lookup table, in exchange for a small amount of extra work per frame.
The extra work (a few extra loads/mul/adds) is negligible, and can execute in parallel.
The reduction in cache misses almost certainly outweighs any added cost.
The table is generated at runtime, and takes less than 0.02ms on my computer.
Compiler support for loading/storing multiple registers at once (i.e vld1q_f32_x4) seems very poor, so avoiding them for now.
Also switched to aligned stores with SSE. Although both SSE and NEON support unaligned stores, there is more likely to be a penalty to them, i.e when crossing a cache line. So might as align them.
Use DBus to query Systemd to check if the pipewire-pulse service is in the "running" state. If it is, then it is certain that Pipewire is being used instead of Pulseaudio as the preferred system mixer.
If DBus support is not enabled or Systemd is not being used on the underlying system, this check will simply fail and the standard driver order will be tested.
- SDL_RWops is now an opaque struct.
- SDL_AllocRW is gone. If an app is creating a custom RWops, they pass the
function pointers to SDL_CreateRW(), which are stored internally.
- SDL_RWclose is gone, there is only SDL_DestroyRW(), which calls the
implementation's `->close` method before freeing other things.
- There is only one path to create and use RWops now, so we don't have to
worry about whether `->close` will call SDL_DestroyRW, or if this will
risk any Properties not being released, etc.
- SDL_RWFrom* still works as expected, for getting a RWops without having
to supply your own implementation. Objects from these functions are also
destroyed with SDL_DestroyRW.
- Lots of other cleanup and SDL3ization of the library code.
Separately checking the state of a file before operating on it may allow
an attacker to modify the file between the two operations. (CWE-367)
Fix by using fstat() instead of stat().
This catches the case where we obtain a logical device while the default is
changing in another thread, so you accidentally end up with the previous
default physical device locked and returned from ObtainLogicalAudioDevice.
When no source devices are connected, the default source string can contain a sink name. If the default source and sink match, it will be caught as a sink device first and handled correctly, but if the default sink/source don't match, which happens when the sink is an HDMI output and the source is still an onboard audio chipset output name, an assert can result since the requested source device won't be flagged as a capture device. Rather than asserting, simply don't assign default devices that don't match the correct capabilities, as it's not an uncommon scenario and can be handled gracefully.
Additionally, if asserting is a no-op in release mode, sinks can be returned as sources and vice versa, which is incorrect.
This updates GetAudioDevices() to have the same behavior as SDL_GetJoysticks() where the return value will only be NULL if there is an error. Returning no devices will return a valid array containing NULL.
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.
Brick
Frank Praznik
Ryan C. Gordon
Sam Lantinga
Anonymous Maarten
Mingjie Shen
Mathieu Eyraud
Anonymous Maarten