[Bug]: Sound non-functional in nightly linux-generic builds

[JGRennison]

Version of OpenTTD

master

Expected result

Sound (sound effects, music) works.

Actual result

Running the current nightly builds with -d driver=1 produces:

dbg: [driver] Probing sound driver 'sdl' failed with error: dsp: No such audio device
dbg: [driver] Successfully probed sound driver 'null'
dbg: [driver] Fluidsynth: sf (null)
dbg: [driver] Fluidsynth: samplerate 11025

Resulting in no audio output.

13.x linux-generic builds work fine.

Forwarded from: JGRennison/OpenTTD-patches#552

This appears to coincide with #10484.

Steps to reproduce

See above

[TrueBrain]

Silly question, but how about music? Or are both non-functional?

[JGRennison]

Music doesn't work either. Fluidity outputs sound samples back to OpenTTD, rather than talking to the sound devices directly. (Someone wrote a helpful comment about this in the workflow, I wouldn't have guessed this otherwise :P).

[tyrone-sudeium]

My theory as to what happened is that by removing SDL2-devel from yum and moving it to vcpkg, we're now responsible for compiling our own SDL2 from source, and the audio drivers this custom SDL2 supports is determined by whichever headers are available at compile time. Based on the workflow comment:

# The yum variant of fluidsynth depends on all possible audio drivers,
# like jack, ALSA, pulseaudio, etc. This is not really useful for us,
# as we route the output of fluidsynth back via our sound driver, and
# as such do not use these audio driver outputs at all.
# The vcpkg variant of fluidsynth depends on ALSA. Similar issue here.
# So instead, we compile fluidsynth ourselves, with as few
# dependencies as possible. This currently means it picks up SDL2, but
# this is fine, as we need SDL2 anyway.

We are deliberately not providing the headers for any of the audio drivers. However, since we're now compiling SDL2 from source, it also relies on the headers for those audio drivers for proper audio support, essentially our SDL2 is built without any audio support at all on Linux (the error message references dsp which I think is an OSS thing, so maybe it's falling back to that? This is some ancient Linux arcana that is far beyond my years).

I'm currently in the process of wrangling the github workflows to test this theory in my own branch, by simply installing pulseaudio-libs-devel and alsa-lib-devel through yum. I'm not sure how much appetite we have for adopting this though, as that pulls in a lot of stuff, but I'm not sure how else to address it.

[Gadg8eer]

I can confirm this bug is true on both vanilla 13.2 and JGRPP 0.54.2 on Steam Deck (which has gotten to be a pretty popular device), so whatever makes this unappetizing, you might just have to swallow it anyway.

[tyrone-sudeium]

My build finished, and it became immediately clear why we avoid pulling in those dependencies from yum:

Tall image

As you can see the amount of stuff pulled into lib becomes enormous, perhaps unmanageably so. Another problem is that yum is very, very slow, and simply adding those two dependencies added more than 20 minutes to the workflow time. However, it does fix the bug. The artifact produced by my workflow has working sound.

What's doubly weird though is with my artifact I can delete the entire contents of lib (except for libfluidsynth.*) and the game still works. Sound and all. Maybe this isn't true for every version of every distro though, I don't know.

[TrueBrain]

Bit of a backstory how SDL works:

If during compiling of SDL the header-files of audio drivers are available, it will add support for that audio driver. But, on runtime, it will use dlopen to actually load the driver and use it. This means SDL doesn't depend on the library.

What went wrong in the earlier mentioned commit, is that the header files were no longer there, so SDL doesn't add support for that driver. An otherwise easy fix.

I will add support for jack, alsa and pulse soon.

[YellowOnion]

I'm having issues with JGR and multimonitor detection, Perhaps there's some other headers missing that might be worth investigating?

[LordAro]

Issues with JGRPP should be reported to his repo. Possible this change hasn't been ported yet

[YellowOnion]

@LordAro I bring it up here, because it seems like a build issue, just like this SDL sound issue, infact building the JGR version on my distro fixes both the multimonitor issue and the sound issue, I assume it's because some xorg deps are missing.