While we can always spend time investigating these kinds of issues, Blender’s audio support without SDL can still output to various back-ends via OpenAL as well as native support for PulseAudio on Linux, CoreAudio on macOS and WASAPI on MS-Windows.
Given this, the motivation to keep support for another audio back-end isn’t high.
To be removed:
SDL audio output won’t be included in release builds
(release builds will use WITH_SDL=OFF).
Blender’dynamic SDL linking will be removed.
(the WITH_SDL_DYNLOAD option, called sdlew internally).
SDL will be removed from pre-built libraries under ./lib/.
Edit: stand-alone cycles uses SDL, so the library can be kept in lib/ for now.
To be kept:
The WITH_SDL build option will remain, when enabled, audio output with SDL will be possible as before.
The WITH_GHOST_SDL build option, allowing Blender to run with SDL for windowing (used by Haiku).
Unless there are strong reasons to keep SDL support for 4.3, we intend to disable support for the up-coming release.
Something we’ve discusses in the Cycles chat root: cycles standalone depends on it. At a very least we’d need to coordinate that with the Cycles team.
Keeping in mind that Cycles is a BF project, and SDL doesn’t really need to be updated that often, and updates are typically easy, are there disadvantages of keeping its precompiled libraries?
Maybe @LazyDodo has some strong opinion here as well?
Nah SDL is a pretty small, quick to build and trouble free dep, if the cycles team wants to keep it it’s perfectly fine with me. Think brecht mentioned he may want a flag change, which is also fine with me.
Judging from the ticket linked which now has been root caused (and a pretty interesting one at that) I’m not seeing any clear reasons to disable SDL anymore (but will go along with whatever gets decided)
@sergey OK to keep in ./lib/ for cycles (edited post).
Even though the issue has been fixed in SDL2 I’d still rater disable SDL in release builds since we don’t gain much from it’s inclusion.
It’s one extra library to track, update etc (even integrating the fix from the new SDL2 takes us time).
SDL3 has recently been released with an updated API which seems different enough that sdlew and Blender’s SDL integration may need updating. Admittedly I’m not sure how much work this would be, just noting that this is something we would have to spend time on.