Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New game fails to start after upgrading FluidSynth to version 2.2.0 #9117

Closed
ghisvail opened this issue Apr 27, 2021 · 13 comments · Fixed by #9181
Closed

New game fails to start after upgrading FluidSynth to version 2.2.0 #9117

ghisvail opened this issue Apr 27, 2021 · 13 comments · Fixed by #9181

Comments

@ghisvail
Copy link
Contributor

OpenTTD works fine with FluidSynth version 2.1.8. When I upgrade its Flatpak runtime with FluidSynth version 2.2.0, the game is no longer playable.

Version of OpenTTD

OpenTTD version 1.11.1 installed with Flatpak on Debian 11.

Expected result

New game starts successfully.

Actual result

New game starts but the progress bar of the initialization process hangs towards the end and the user interface becomes frozen. No way to escape the game apart from killing the app.

Steps to reproduce

Install the game with FluidSynth version 2.2.0, launch OpenTTD, start a new game.
@glx22
Copy link
Contributor

glx22 commented Apr 27, 2021

It seems there are some breaking changes in fluidsynth 2.2.0 https://www.fluidsynth.org/api/RecentChanges.html#NewIn2_2_0

@James103
Copy link
Contributor

Expecially note the following two lines of the changelog:

  • fluid_file_callbacks_t now uses long long as file-offset type (see fluid_long_long_t). This is a breaking change, which allows to load SoundFonts bigger than 2GiB on Windows. This change required to bump fluidsynth's SOVERSION.
  • Various fluid_event_*() functions that received a "value" argument of type short now receive an int argument in preparation for MIDI 2.0 support

@ghisvail
Copy link
Contributor Author

Although these are breaking changes from an ABI standpoint, the app still compiles and launches fine. I can see the start screen, navigate the menu and listen to the intro song. It's only the new game process which ultimately hangs for some reason.

@glx22
Copy link
Contributor

glx22 commented Apr 27, 2021

I tried running it in gdb, and I can see it hangs on fluid_player_join() in MusicDriver_FluidSynth::StopSong(), but I don't know why.

@ghisvail
Copy link
Contributor Author

On a side note, according to the docs, fluid_player_join always return FLUID_OK so the following line is dead code.

@ghisvail ghisvail mentioned this issue Apr 27, 2021
Closed
@glx22
Copy link
Contributor

glx22 commented Apr 27, 2021

Oh BTW I only tested with version available in flatpak install openttd so I don't know which version of fluidsynth is used, but it hangs.

@ghisvail
Copy link
Contributor Author

There is an update coming which downgrades FluidSynth to version 2.1.8 in the runtime. If it hangs, then you are still using the runtime with version 2.2.0 which was pushed last night.

@LordAro
Copy link
Member

LordAro commented Apr 27, 2021

Even Arch is not yet updated to fluidsynth 2.2 ! :)

@ghisvail
Copy link
Contributor Author

Even Arch is not yet updated to fluidsynth 2.2 ! :)

Well then, they should not :-)

@ghisvail
Copy link
Contributor Author

@glx22 If needed, I can provide a build with FluidSynth v2.2.0 in a separate PR for testing. Please let me know.

The Flatpak version is back to version 2.1.8 for now.

@glx22
Copy link
Contributor

glx22 commented May 1, 2021

I tried building manually Fluidsynth from source (git clone), and building OpenTTD against 2.1.8 works fine, while against 2.2.0 it hangs at the end of map generation, waiting for music to stop. Maybe related to FluidSynth/fluidsynth@8413c35

@rubidium42
Copy link
Contributor

rubidium42 commented May 2, 2021 •
edited

Ah, figured out what I was doing wrong. The problem is introduced by FluidSynth/fluidsynth@6769237. The issue that glx22 mentioned is a fix to solve something the commit I linked broke, but not our use case. As far as I could figure out the new "stopping" state never progresses to "stopped" for us, so the join that waits until it is "stopped" will never return.

I made an upstream bug report: FluidSynth/fluidsynth#872. Maybe our code is wrong, in which case we still have something to fix, but I hope the developers of FluidSynth will tell us what is wrong about that code.

rubidium42 added a commit to rubidium42/OpenTTD that referenced this issue May 2, 2021
@rubidium42
Fix OpenTTD#9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping song
ddf448c 
In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else hell
a lock, so the state would never get to stopped and join would never return.
rubidium42 added a commit to rubidium42/OpenTTD that referenced this issue May 2, 2021
@rubidium42
Fix OpenTTD#9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping song
ee59a2d 
In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
rubidium42 added a commit to rubidium42/OpenTTD that referenced this issue May 3, 2021
@rubidium42
Fix OpenTTD#9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping song
b9bbeb9 
In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
@rubidium42 rubidium42 mentioned this issue May 3, 2021
Merged
LordAro pushed a commit that referenced this issue May 3, 2021
@rubidium42
Fix #9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping song (#9181
6bd7f88 
)

In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
LordAro pushed a commit to LordAro/OpenTTD that referenced this issue May 3, 2021
@rubidium42 @LordAro
Fix OpenTTD#9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping s…
4678799 
…ong (OpenTTD#9181)

In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
LordAro pushed a commit that referenced this issue May 3, 2021
@rubidium42 @LordAro
Fix #9117, 04ce1f0: [Fluidsynth] Infinite wait when stopping song (#9181
f959554 
)

In FluidSynth 2.2.0 an extra state was added to denote stopping. To transition
from this state to a stopped state the rendering needs to be running. Since
04ce1f0 locking was added that skipped the rendering when something else held
a lock, so the state would never get to stopped and join would never return.
@ghisvail
Copy link
Contributor Author

ghisvail commented May 4, 2021

I have updated the Flatpak release with OpenTTD v1.11.2 and FluidSynth v2.2.0.

I confirm the issue is fixed 👍

Thanks to all the people involved

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix #9117, 04ce1f07: [Fluidsynth] Infinite wait when stopping song rubidium42/OpenTTD
5 participants
@ghisvail @glx22 @LordAro @rubidium42 @James103