Keep building linux AppImage with libmad, resolves issue #756

[j4reporting]

introduced with commit 8b42de7 and commit 7068875
this breaks audio for newer linux systems If pulseaudio ( libpulse0 ) is used by the system.

This can probably be reverted when we update the docker image to Ubuntu 22.04 at some point.

[Novum]

@vsonnier thoughts?
It really depends why we want 123 instead of mad? It's slightly faster and reads corrupt MP3s? I think we can live with mad for now.

[Novum]

If we want to keep 123 I think the correct fix is to include the old .so files from Ubuntu 20.04 that are incompatible in newer distros.

[Novum]

@j4reporting Could you put up an alternative PR with libpulse and dependencies in the AppImage? I don't really think we care about 2MB extra if it solves the issue and we don't have divergence in what we ship.

[vsonnier]

@Novum

@vsonnier thoughts?
It really depends why we want 123 instead of mad? It's slightly faster and reads corrupt MP3s? I think we can live with mad for now.

Taking into account the .so Hell seen in #756 and this present PR I would simply put back libmad for Linux targets entirely, we have lived without libmp123 for a long time after all.
As @sezero said I followed @andrei-drexler on the change assuming it was because libmp123 was maintained contrary to libmad ?

Now If we put back libmad for Linux targets only, we have 2 implementations to maintain although I do not expect to see MP3 bugs very often...
On the other hand, I would like to keep the same code used as in QuakeSpasm and Ironwail for those major targets Windows and MacOS, so I would rather not revert libmp123 for those.

So there is no ideal solution, so I'll let you choose, either this PR or reverting to libmad (as default) for Linux targets ?

[j4reporting]

for what's it worth, quakespasm still has mad as default option
https://github.com/sezero/quakespasm/blob/271d588ef2d7d51328e0f349d1111f664c63cf6a/Quake/Makefile#L25-L26

[vsonnier]

for what's it worth, quakespasm still has mad as default option https://github.com/sezero/quakespasm/blob/271d588ef2d7d51328e0f349d1111f664c63cf6a/Quake/Makefile#L25-L26

I'm not attached to libmp123, so in that case we could also pretend the libmp123 changes never occured and continue to use libmad for all, including Windows and MacOS.

I don't see the supposed faster decoding for libmp123 matters in any way, except on Rasberry PI-like targets ?

[j4reporting]

@j4reporting Could you put up an alternative PR with libpulse and dependencies in the AppImage? I don't really think we care about 2MB extra if it solves the issue and we don't have divergence in what we ship.

#758

[sezero]

it was because libmp123 was maintained contrary to libmad ?

libmad is 'maintained' (ahem) at a different place for
some time: https://codeberg.org/tenacityteam/libmad
Fedora has switched to using it from that site for some
time, too.

However, libmad has been rock solid and doesn't need much
maintenance than what distros has been patching, and the
version I've been including in qs and other projects has
always been up to date.

so I'll let you choose, either this PR or reverting to libmad (as default) for Linux targets ?

Yup

@j4reporting Could you put up an alternative PR with libpulse and dependencies in the AppImage? I don't really think we care about 2MB extra if it solves the issue and we don't have divergence in what we ship.

#758

I'm really not fond of providing the appimage, but this? ughh. why not package the kernel, glibc and x11 along with others! ugh...

[Novum]

it was because libmp123 was maintained contrary to libmad ?

libmad is 'maintained' (ahem) at a different place for some time: https://codeberg.org/tenacityteam/libmad Fedora has switched to using it from that site for some time, too.

However, libmad has been rock solid and doesn't need much maintenance than what distros has been patching, and the version I've been including in qs and other projects has always been up to date.

so I'll let you choose, either this PR or reverting to libmad (as default) for Linux targets ?

Yup

@j4reporting Could you put up an alternative PR with libpulse and dependencies in the AppImage? I don't really think we care about 2MB extra if it solves the issue and we don't have divergence in what we ship.

#758

I'm really not fond of providing the appimage, but this? ughh. why not package the kernel, glibc and x11 along with others! ugh...

Only stable interface on Linux is the kernel. No one else gives a f***. That's why AppImages are needed. There is no other way until everyone keeps things compatible. Which is going to be never.

[j4reporting]

Only stable interface on Linux is the kernel. No one else gives a f***. That's why AppImages are needed. There is no other way until everyone keeps things compatible. Which is going to be never.

the compatibility is not that bad, the problem is really that mpg123 is requested by all kind of audio related stuff by the system, and the runtime can´t open two different libraries with the same name.

little experiment on Fedora41:

extracted the binary and libFLAC.so.8 from the 1.31.3 appimage (fedora41 has libFLAC.so.10 ) to /tmp

here is the ldd output with LD_LIBRARY_PATH to find libFLAC.so.8

LD_LIBRARY_PATH=/tmp ldd  /tmp/vkquake_1.31.3_appimage_bin 
	linux-vdso.so.1 (0x00007f0cf3177000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f0cf2143000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f0cf205d000)
	libSDL2-2.0.so.0 => /lib64/libSDL2-2.0.so.0 (0x00007f0cf1e89000)
	libvulkan.so.1 => /lib64/libvulkan.so.1 (0x00007f0cf1e0d000)
	libmpg123.so.0 => /lib64/libmpg123.so.0 (0x00007f0cf1db1000)
	libFLAC.so.8 => /tmp/libFLAC.so.8 (0x00007f0cf1d6d000)
	libvorbisfile.so.3 => /lib64/libvorbisfile.so.3 (0x00007f0cf1d62000)
	libopusfile.so.0 => /lib64/libopusfile.so.0 (0x00007f0cf1d53000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0cf1d4e000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f0cf3179000)
	libogg.so.0 => /lib64/libogg.so.0 (0x00007f0cf1d44000)
	libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007f0cf1d12000)
	libopus.so.0 => /lib64/libopus.so.0 (0x00007f0cf1cab000)

so it loads the newer libmpg123 with the mpg123_info2 symbol

objdump  -T /lib64/libmpg123.so |grep mpg123_info
00000000000165f0 g    DF .text	00000000000001b7  Base        mpg123_info
00000000000167b0 g    DF .text	00000000000001b7  Base        mpg123_info2

start with LD_LIBRARY_PATH=/tmp ./vkquake_1.31.3_appimage_bin -basedir <path>/vkquake/
manages to open a pulse audio device. Something the appimage did not manage to do ( it seem to fail silently and retry ALSA instead ) and played some mp3 music files

Found SDL version 2.30.11
Detected 8 CPUs.
Initializing vkQuake 1.31.3
Built with GCC 9.4.0

Exe: 16:04:20 Nov  8 2024

SDL audio spec  : 44100 Hz, 1024 samples, 2 channels
SDL audio driver: pulseaudio - Built-in Audio Analog Stereo, 65536 bytes buffer

]music track02.mp3
]music track03.mp3
]music track42.mp3
]music track69.mp3
]music track96.mp3

strace for the AppImage shows that SDL indeed tries to open pulse first but fails.

strace ./vkquake.AppImage -basedir ~/games/vkquake 2>&1 |grep -Ei "pulse|alsa|mpg123" 
openat(AT_FDCWD, "/tmp/.mount_vkquakURFINn/usr/bin/../lib/libmpg123.so.0", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/tmp/.mount_vkquakURFINn/usr/lib/libmpg123.so.0", O_RDONLY) = 12
openat(AT_FDCWD, "/tmp/.mount_vkquakURFINn/usr/lib/libmpg123.so.0", O_RDONLY) = 16
openat(AT_FDCWD, "/tmp/.mount_vkquakURFINn/usr/bin/../lib/libpulse.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib64/libpulse.so.0", O_RDONLY|O_CLOEXEC) = 71
openat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v4/libpulsecommon-17.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v4/", 0x7ffef1a8f6d0, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v3/libpulsecommon-17.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v3/", 0x7ffef1a8f6d0, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v2/libpulsecommon-17.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/usr/lib64/pulseaudio/glibc-hwcaps/x86-64-v2/", 0x7ffef1a8f6d0, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/pulseaudio/libpulsecommon-17.0.so", O_RDONLY|O_CLOEXEC) = 71
newfstatat(AT_FDCWD, "/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=10092, ...}, 0) = 0
openat(AT_FDCWD, "/usr/share/alsa/alsa.conf", O_RDONLY) = 71

Unfortunately on Ubuntu22/Mint22 ALSA opens libsndfile.so too. Fedora 40+ and probably Ubuntu24 use pipewire and the alsa libraries are not tied to libsndfile.so any more.

[Axel-Reactor]

I still don't understand why libmpg123 loads pulse?

[sezero]

I still don't understand why libmpg123 loads pulse?

No: libpulse loads libsndfile, libsndfile loads libmpg123

[Axel-Reactor]

I see. Okay, let's use mad for AppImages for now until we can get to a newer Ubuntu. You're right.

[j4reporting]

actually, it's libpulse -> libpulsecommon -> libsndfile -> /various codecs/

and here is the kicker: libsndfile does NOT load libmpg123 on Ubuntu 22.04!
Apparent;ly it does so on Mint 22.

So, I expect the 1.31.3 AppImage to work on Ubuntu 22 (pulse) and 24 (ALSA)

ubuntu-2204:/$ objdump -p /lib/x86_64-linux-gnu/libpulse.so  |grep NEEDED
  NEEDED               libpulsecommon-15.99.so
  NEEDED               libm.so.6
  NEEDED               libdbus-1.so.3
  NEEDED               libc.so.6

ubuntu-2204:/$ objdump -p /lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-15.99.so  |grep NEEDED
  NEEDED               libm.so.6
  NEEDED               libsndfile.so.1
  NEEDED               libdbus-1.so.3
  NEEDED               libX11-xcb.so.1
  NEEDED               libX11.so.6
  NEEDED               libxcb.so.1
  NEEDED               libsystemd.so.0
  NEEDED               libasyncns.so.0
  NEEDED               libapparmor.so.1
  NEEDED               libc.so.6

ubuntu-2204:/$ objdump -p /lib/x86_64-linux-gnu/libsndfile.so.1  |grep NEEDED
  NEEDED               libFLAC.so.8
  NEEDED               libvorbis.so.0
  NEEDED               libvorbisenc.so.2
  NEEDED               libopus.so.0
  NEEDED               libogg.so.0
  NEEDED               libm.so.6
  NEEDED               libc.so.6

ALSA:
The sdl2 alsa backend loads the alsa plugin libasound_module_pcm_pulse.so (pulse audio server )

ubuntu-2204:/$ objdump -p /usr/lib/x86_64-linux-gnu/alsa-lib/libasound_module_pcm_pulse.so |grep NEEDED
  NEEDED               libpulse.so.0
  NEEDED               libasound.so.2
  NEEDED               libc.so.6

and again down the line libsndfile is loaded via libpulse

I guess the difference between Ubuntu22 and Mint 22 is the aditional dependency of libsndfile -> libmpg123

Ubuntu 24 and current Fedora fail with pulse but succeed with ALSA

ubuntu24:~$ objdump -p /lib/x86_64-linux-gnu/libsndfile.so.1 | grep NEEDED
  NEEDED               libFLAC.so.12
  NEEDED               libvorbis.so.0
  NEEDED               libvorbisenc.so.2
  NEEDED               libopus.so.0
  NEEDED               libogg.so.0
  NEEDED               libmpg123.so.0
  NEEDED               libmp3lame.so.0
  NEEDED               libm.so.6
  NEEDED               libc.so.6

ALSA via pipewire audio server does not have the alsa-plugin libs => libsndfile is not loaded and SDL2 can open the audio device successfully.

let's keep using libmad for the linux AppImages 🙄