News:

Beta test the new forum at https://simutrans.forum/
Use the "Forum Search"
It may help you to find anything in the forum ;).

New music backend for Simutrans: fluidsynth

Started by Roboron, August 29, 2020, 07:56:10 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Roboron

#35
Quote from: prissi on February 08, 2021, 02:16:49 PMWhy should SDL_mixer be removed.

Because it is a buggy piece of software that has caused many issues (apart from greater loading times and the unfriendliness of having to set an environment variable).

=> Crashing on startup, fresh install Mint 20.04 (ubuntu) + version 120.4.1 build 1
=> Simutrans from the DEB Repo crashes with LM 20.1

Quote from: Andarix on January 15, 2021, 02:04:02 PMUbuntu 20.04 and SDL_mixer/SDL2_mixer not work.

The Simutrans version from the distribution repo doesn't work either.

As a result, mixer does not work with all derived distributions either.

There are already several reports about this.

Quote from: prissi on February 08, 2021, 02:16:49 PMMaybe there are systems, where fluidsynth is not available but SDL_mixer is.

Could you name such a system? At least on my system fluidsynth is a dependency of sdl_mixer, so it is highly unlikely that a system with sdl_mixer does not have fluidsynth available. We are just cutting the middleware here.

At the very least we should remove it from being an option on linux now that we have an alternative, so those bug reports stop coming.

EDIT: A list of systems supported by fluidsynth. Even Haiku is on the list.

prissi

Seems like fluidsynth will be anyway choosen as soon as SDL_mixer is selected. (Beos/Haiku was the second OS to have native midi support, so I am not sure fluidsynth is needed there anyway. But that build is somehow broken anyway.) But I still would keep this patch and removing SDL_mixer two seperate things. So if TurfIt does not submit it, I will do it.

Roboron

Quote from: prissi on February 08, 2021, 11:40:04 PMBut I still would keep this patch and removing SDL_mixer two seperate things.

Yes, of course. I'll open a new thread when this get merged.

TurfIt

#38
I'm working on cleaning up the Makefile before committing. It throws a "expr: syntax error: unexpected argument '1'" if USE_FLUIDSYNTH_MIDI is not defined. Trying to decide on the cleanest way to eliminate...

EDIT: Done.

For SDL_Mixer, there never should have been a sdl2_mixer selection - sdl_mixer was for sdl1, presumably worked, sdl2 added but no testing done with mixer, commit adding sdl2_mixer to makefile even says 'untested', so those that chose to deploy this....

If anything, longterm the idea would be to remove the non-mixer. i.e. The game sound effects are also rather horrid, in need of overhaul, which would need the flexibility of mixer IMO.

prissi

The stable SDL2 and the nightly SDL2 for Linux does not use SDL_mixer for exacty that reason.

Andarix

SDL_mixer/SDL2_mixer does not work on Ubuntu 20.04 and derived

Roboron

Quote from: TurfIt on February 09, 2021, 01:02:46 AMIf anything, longterm the idea would be to remove the non-mixer. i.e. The game sound effects are also rather horrid, in need of overhaul, which would need the flexibility of mixer IMO.

Oh, the sounds. That's like, opening the Pandora box of Simutrans. I don't see it happening anytime (soon... or ever?), but that's enough of a point for me, I guess. I'll move onto the next thing and forget about the mixer*...

Anyway, thank you TurfIt for helping me with this. It's such an improvement to my current Simutrans experience, I'm very glad <3

* That's it, until I see maintainers building against sdl_mixer again for the next release, because why bother updating the build patches if "it builds" (built does not mean it works, but it's not like they even test their packages). I better start writing those angry emails.


Roboron

I was testing this on the mac VM and fluidsynth complained that "sdl2" was not a valid sound driver, instead offered "coreaudio", "portaudio" and another one I don't remember.

So, a small follow-up patch that adds an extra #ifdef for MacOS. It also includes the necessary changes to distribute.sh to prepare a bundle including fluidsynth.

P.D.: My VM doesn't have sound, so a third user made the testing for me this time and confirmed it works.

prissi

#44
Why using fluidsynth with coreaudio, when there is already coreaudio support?

Also the Makefile does not use pkg-config on the other OS, like MacOS. Does this mean it is not needed there?!?

Anyway, in with r9627 minus fluidsynth distribution, unless I get an explanation why MacOS needs fluidsynth. Because adding this breaks the Github nightly builds on MacOS, which is hard enough to set up. Why libgthread? My googling found not much, seems more like a system library.

Roboron

Quote from: prissi on February 12, 2021, 02:13:49 AMWhy using fluidsynth with coreaudio, when there is already coreaudio support?

Because as already reported the current mac backend is not working. Thus, until someone with a Mac fix it, this seems to be the only working solution.

Quote from: prissi on February 12, 2021, 02:13:49 AMadding this breaks the Github nightly builds on MacOS, which is hard enough to set up

I agree, I don't think the music is valuable enough for troubling with nightly builds anyway. Maybe, just keep those lines commented out, as it will be useful at least for me when compiling the next stable.

Quote from: prissi on February 12, 2021, 02:13:49 AMWhy libgthread?

Sorry, I should have said, fluidsynth won't work without it. At least the Mac of the user who did the test for me didn't have it, so I had to add it.

prissi

Thanks for the clarification. As I understood, your patch in the other thread fixes the midi support to no longer crashing.

As far as I could find out, the libgthread is the homebrew variant of the C-lib threading support. Since Mac uses the native threading support, I wonder if these do not badly clash.

Roboron

Quote from: prissi on February 12, 2021, 12:44:44 PMyour patch in the other thread fixes the midi support to no longer crashing

Yes, it stops the crashing but nothing more, music won't work. Currently there's no practical difference between compiling with AVFoundation and compiling with no_midi.cc lol

Quote from: prissi on February 12, 2021, 12:44:44 PMlibgthread is the homebrew variant of the C-lib threading support

Nothing to do with homebrew, libgthread is part of glib, a multiplatform C library by GNOME, which is needed by fluidsynth. As far as I know libgthread is just a wrapper for posix pthread. Not sure what the advantages are.

Yona-TYT

Apparently I have a font installed, but I still have no audio / music.

Roboron

If you see "Music disabled/unavailable" then the audio driver failed to initialize. Run Simutrans on the CLI with debug option and you will see at what point it fails. Reply back with this information so I can help you debugging it.

Yona-TYT

Quote from: Roboron on February 12, 2021, 09:37:32 PM
If you see "Music disabled/unavailable" then the audio driver failed to initialize. Run Simutrans on the CLI with debug option and you will see at what point it fails. Reply back with this information so I can help you debugging it.

gdb '/home/yonatyt/Downloads/simutrans/sim'
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/yonatyt/Downloads/simutrans/sim...done.
(gdb) run
Starting program: /home/yonatyt/Downloads/simutrans/sim
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Using data directory /home/yonatyt/Downloads/simutrans/
Reading low level config data ...
parse_simuconf() at config/simuconf.tab: Reading simuconf.tab successful!
Init done.
parse_colours() at config/simuconf.tab: Reading simuconf.tab successful!
[New Thread 0x7ffff7fbb700 (LWP 3194)]
[New Thread 0x7fffdb7f0700 (LWP 3195)]
Calculating textures ...done
[Thread 0x7fffdb7f0700 (LWP 3195) exited]
[Thread 0x7ffff7fbb700 (LWP 3194) exited]
[Inferior 1 (process 3174) exited normally]


Roboron

Sorry, I mean the debug option of simutrans ("sim -debug 5") to show debug messages xD

Yona-TYT

I don't know where this option is, you mean the makefile?.

Roboron

nono, when running simutrans on the CLI, you can add some options appending "-option [value]".

"simutrans -help" gives you a list of options
"simutrans -fullscreen" starts the game in fullscreenmode
"simutrans -debug 5" show debug messages

Etcétera

Andarix

see simutrans/readme.txt -> Simutrans command line options

and see simuconf.tab

Quote# Set this for playing MIDI music with your preferred soundfont.
# Need Fluidsynth support.
# A recommended lightweight (30 MB) soundfont is PCLite:
#   http://www.personalcopy.com/sfarkfonts1.htm
#   https://src.fedoraproject.org/repo/pkgs/PersonalCopy-Lite-soundfont/PCLite.sf2/629732b7552c12a8fae5b046d306273a/
# But there are many more, including greater quality ones.
# Set either the full path or the name of the .sf2 soundfont saved into the "music" directory
soundfont_filename = PCLite.sf2

Yona-TYT

#55
Edit.
Text in file.

Roboron

Too much text to be displayed on the forum, apparently. Upload a .txt or use a service like pastebin

=> https://pastebin.com/


Roboron

Warning: dr_init_midi():        FluidSynth: Set MIDI driver sdl2 failed.

Fluidsynth failed to use the SDL2 driver. This may be related to some incompatibility between your versions of SDL2 and Fluidsynth (or some other issue idk).

Try to use pulseaudio instead. Apply this patch and compile again. If it works, I'll add pulseaudio as fallback driver.

Yona-TYT

Now he says:
Warning: dr_init_midi():    FluidSynth: Set MIDI driver pulseaudio failed.


Roboron

I can't really say I'm surprised, since pulseaudio was surely what SDL2 uses internally.

Let's keep going down the stack, replace "pulseaudio" with "alsa" and try again.

Yona-TYT

I am using linux mint mate, pulseaudio is what appears running here.

Roboron

Yes, but pulseaudio is just a middleware for using ALSA. So try using ALSA directly by replacing "pulseaudio" with "alsa" in the previous patch.

=> https://wiki.archlinux.org/index.php/PulseAudio

QuotePulseAudio is a general purpose sound server intended to run as a middleware between your applications and your hardware devices, either using ALSA or OSS.

Yona-TYT

Warning: dr_init_midi(): FluidSynth: Set MIDI driver alsa failed.
Message: simu_main(): Midi disabled ...


:(

TurfIt

I don't really care for Simutrans forcing use of particular drivers, but leaving them automatic is possibly worse, especially when it comes to Linux and sound support (Just read old bug reports...).

Fluidsynth music backend is intended for a minimal fluidsynth to be statically linked. Simutrans with Linux requires SDL2 graphic backend. Hence Simutrans Fluidsynth requiring SDL2 is reasonable. Compile your Fluidsynth library "correctly".  (See Makefile for minimal mingw build - same thing for linux - different target).

Roboron

#65
Quote from: Yona-TYT on February 13, 2021, 10:01:50 PM:(

Seems like we are out of luck today. One last try, I remember fluidsynth automagically set the driver according to compile options (if not defined by the program - but that didn't work for me). Please test the attached patch.

If this doesn't work, TurfIt is right - problem will be better solved by compiling your own version of fluidsynth* (or by writing angry emails to linux mint maintainers).

* For the next release on Steam I will have to include a Fluidsynth library to link to, so you can wait for that too.

P.D.: I see minimum  Fluidsynth version for SDL2 driver is 2.1.0.. What's the Fluidsynth version in your repositories?

Roboron

Sorry for necroing. I set the Arch/Fedora system path wrong in my last patch when copy-pasting, I didn't notice until now. Please commit this fix.

prissi


Roboron

Patch: SDL audio initialization should only be checked if using SDL2 driver. And without this change, compilation on Windows is not possible. Please commit.

(this is how it was before, an unfortunate chain of changes (not by me) broke it)

ceeac