Audio no longer works with SDL

SDL Development
1

I have reinstalled my Linux Mint. And also compiled and installed all the SDL3 and SDL3_mix libs.

Now I can no longer play audio, regardless of whether it is SDL_Audio or SDL_mix.

It also doesn’t matter what format, whether it is MP3, WAV or Flac.

The first error comes up with SDL_init( SDL_INIT_AUDIO....

SDL_Get Error spits out the following: No available audio device

I strongly suspect that some package still needs to be installed.

VLC Player and others work.

It can’t be the current SDL3 files, it works on my second PC with the same libs.

2

As GuildedDoughnut discovered in another thread, what libraries that you have installed when building SDL matters so if you built SDL3 from source you might have to rebuild it again after you have installed the missing libraries. Make sure you have installed the development versions of these libraries.

Pay attention to the output after running the first cmake command (cmake -S . -B build). It shows a long list of libraries. If it detected the library it should show “ON” on the same row. On Linux I know that at least ALSA, PulseAudio and PipeWire are related to audio. I’m not sure if you need all of them.

1 Like
3

I can’t say exactly what I tried. At some point a message appeared saying that fluidsynth was missing.
When I installed the package, it suddenly worked.

sudo apt install fluidsynth
4

Is that ‘usual’? It’s not something I would have anticipated, but then I’m not a Linux user and I find many things about that platform strange!

5

That is entirely normal, yes.
And I’d expect it to be the same on Windows as well, TBH, unless you bundle the dependencies with your lib.
CMake (or also ./configure from autotools) can check the available libraries, and set build defines (like HAVE_LIBFOO or whatever) based on that, so only the ones that are found are used.
Of course the build systems can also insist on libraries being present and error out when they’re not, but it’s usual to make dependencies on non-essential libraries (for example ones providing support for additional file types) optional.

6

I’ve never felt the need to build SDL at all on Windows, I use the pre-built binaries (SDL2.dll, SDL2_ttf.dll, SDL2_net.dll). Since I’m bundling them with a distributed app, any configuration based on my own setup would be inappropriate.

7

Well, if you would build SDL (or the addon libs, this is more relevant for SDL_Image and SDL_Mixer etc, I think) on Windows yourself (e.g. to support Windows on ARM), you’d run into the same behavior.

On other platforms (than Windows x86+x64 and macOS) you do have to build yourself (unless you want to use the possibly outdated versions that your operating system hopefully ships), because SDL doesn’t provide pre-built binaries for them.

8

Me neither, I can’t even manage to install the C compiler and Windows.
So I built my DLLs from Linux with a cross compiler.

9

We have to build SDL3 (and SDL3_mixer, SDL3_image, etc.) if we want to test the latest version. There was a prerelease of SDL3 some time ago (that I can’t seem to find anymore) but a lot has changed since then.

10

Up until now it was never an issue for me because I was building on a system that I had set up well over 4 years ago, so all the dependencies were kind of already installed by the package manager for other programs before I ever started building SDL binaries from source.

But I recently went shopping around for other distributions and the first thing I did was install GCC and build SDL3.
It caught me by surprise.

1 Like
11

I build it myself on Android and iOS, but only those. On Windows, MacOS and Emscripten I use the pre-built binaries; on Linux I rely on what is available from the repository (that may well be out-of-date, but building a ‘universal’ binary for Linux isn’t straightforward, AFAIK).