This has been true for months. I'm playing EMC levels (currently "/usr/share/games/rocksndiamonds/levels/Emerald Mine Club/emc_cosmos_mine_10/22"). These have a startup music (which I don't actually like very much), sounds sort of like "bam bam BAMP bam bam BAMP ...".

SDL1 binaries play that music at startup, until I hit <ESC> to shut them up and get to the main menu.

SDL2 binaries don't.

According to Settings -> Sound & music, I have all three types of sound (normal, looping & music) enabled, with respective volume levels of 2%, 2% and 100%.

Ah -- think I've observed this before -- if I capture stderr of both binaries, the SDL2 output includes these two extra lines:

$ strings -fa /usr/lib/x86_64-linux-gnu/libSDL*mixer*.so.0 | grep -i mp3
/usr/lib/x86_64-linux-gnu/libSDL_mixer-1.2.so.0: Mixer not built with MP3 support
/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0: Mixer not built with MP3 support

... which leads to a different "What the heck?" -- how come -SDL1 can play MP3?!?

These have a startup music (which I don't actually like very much), sounds sort of like "bam bam BAMP bam bam BAMP ...".

You probably have to have played Emerald Mine in 1987 to like that music...

I would sort of expect that just about anything purporting to play music would recognize MP3 format. What the heck?

Building SDL_mixer with external SMPEG library support (for MP3 support) has always been a bit tricky in the past. (Even *finding* a version of SMPEG that does not refuse to compile with SDL_mixer was part of the challenge sometimes.)

Recent versions of SDL2_mixer now include SMPEG directly in the (external libraries) source tree and compile just fine, so MP3 support in SDL2 is now easier than before.

/usr/lib/x86_64-linux-gnu/libSDL2_mixer-2.0.so.0: Mixer not built with MP3 support

OK, that perfectly explains why R'n'D, when compiled against SDL2, does not play MP3s...

... which leads to a different "What the heck?" -- how come -SDL1 can play MP3?!?

Does R'n'D, when compiled against SDL1, really use this library? Not sure how your SDL1 installation behaves, but at least SDL2 dlopen()'s SDL2_mixer, so you may have to strace R'n'D to see what libSDL_mixer.so file it really uses.

Running each under `strace`, I see that they of course open each of those shared objects; and no other *SDL* libraries.

In total they open 38 same libraries; 4-each SDL libraries (which are obviously different); and then SDL1 opens 5 unique libraries while SDL2 opens 26. Of those, I believe the following are audio-related:

As the root cause (SDL2 version of self-compiled new R'n'D 4 branch does not play MP3s) was found, but is beyond the scope of R'n'D development itself, I'll mark this thread as "closed" now.

The final version 4.0.0.0 (just as the already available release candidates) will be packaged with all required SDL2 libraries (including SMPEG for MP3 support), so this will hopefully be no issue anymore with the final release.

If you should encounter similar problems with the last release candidate (currently RC3), please let me know, so this thread can be re-opened.

I need to read back up this to refamiliarize myself with the problem...

Sounds like in part it was because the SDL2 libs I'm using are compiled without some bit of functionality? Or maybe adapt at runtime depending on whether libsmpeg.so is available, and I was missing it?

You're saying that when you build the binaries, you will package with SDL2 and smpeg .so files. But this is not suitable for distros like Debian / Ubuntu where they're going to build their own. I should investigate and make sure that binaries built out of their build env will end up with the right set of everything. And then bugreport to them "update your RnD" -- when 4.0 final is final.

Sounds like in part it was because the SDL2 libs I'm using are compiled without some bit of functionality?

Yes, from your strace output, it seems they were simply compiled without SMPEG support.

Or maybe adapt at runtime depending on whether libsmpeg.so is available, and I was missing it?

Hard to tell... indeed SDL2_mixer may open libsmpeg2.so as a shared object at runtime, if it exists and if MP3 files have to be played. Do you have such a file at the same location as "libSDL2_mixer.so"? But it may also be possible that smpeg2 was compiled into SDL2_mixer directly -- it's included as an external library in a sub-directory of the SDL2_mixer source.

At least for the Android version of SDL2_mixer, smpeg2 compiles as a separate shared library that is loaded at runtime. On the Mac, it seems to be compiled directly into SDL2_mixer.dylib.

That reminds me that I have a similar problem with the last SDL2 versions with Android: I can play WAVs and MODs, but no MP3s, even though the debug log tells me that "smpeg.so" was loaded. So I continue using an older version of SDL2_mixer/smpeg2 for the Android version for now...

You're saying that when you build the binaries, you will package with SDL2 and smpeg .so files.

Yep, right. Therefore the packages are self-contained and contain everything they need to run on any Linux system that is not older than around five or six years. (Excluding things like X11 and C libraries, of course... I didn't want to be THAT self-contained... )

But this is not suitable for distros like Debian / Ubuntu where they're going to build their own.

It doesn't matter, as the libraries included in the R'n'D package do not collide with potentially already installed system wide SDL/SDL2 libraries.

In the past, I never had a Linux system with 100% working SDL/SDL2 libraries with all required/dependent sub-libraries from the distributions repositories. (I've used various SLS, Slackware, SuSE, Debian, Ubuntu and Kubuntu Linux distributions in the past 20 years, and so far I always ended up compiling my own set of SDL, SDL_image, SDL_mixer, SDL_net, mikmod/modplug and smpeg libraries, as the distribution's variants were either non-existing, incomplete or outdated.)

Nevertheless, any distribution's package maintainers are free to bundle R'n'D with all required libraries as they like, so in an ideal world my download package would only ever be a last-resort fallback solution for esoteric distributions, as everybody's using the pre-packaged version installed from the Ubuntu Software Center application (or how it is called).

(At least for Ubuntu and R'n'D 3.3.0.1, this already seems to work fine... But this version is over 6 years old, and the last stable release is over 3 years old.)

I should investigate and make sure that binaries built out of their build env will end up with the right set of everything. And then bugreport to them "update your RnD" -- when 4.0 final is final.

All subdirs build except SDL_mixer/external/libmodplug-0.8.8.4, which builds but fails to install.

...

Ok, got it to work by a bunch of hacking.

Built with its own internal libsmpeg, I was able to get all the way to built & running RnD, which didn't complain about MP3 music, but emitted no actual audible music even with volume cranked all the way up.

I eventually rebuilt SDL_mixer with:

$ ./configure --enable-music-mp3-mad-gpl --disable-music-mp3-smpeg

and RnD it plays music!

But... in-game sounds sound weird. Higher pitched and with sharper cutoff than the SDL1 binary. This is new since building with my own built SDL2 mixer vs. the PPA one I've been using for years. -- in fact, if I run the same binary with LD_LIBRARY_PATH forcing it to either the PPA or my build, it sounds different. And my build crashes with a libc backtrace when I exit. So I'm just going to abandon it, I think...