[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Bug when calling SDL functions from sequencer callback

From: Paul Cohn
Subject: Re: [fluid-dev] Bug when calling SDL functions from sequencer callback
Date: Mon, 19 Nov 2018 19:28:01 -0500

Hey squeek - thanks for your help! I looked into SDL's event APIs and they provide some custom event functions that are thread safe. I changed everything in the callback to use those and that fixed my problem. Guess I should be more aware of the threads going on in my app. Thanks again!

Paul Cohn

On Mon, Nov 19, 2018 at 1:35 AM sqweek E. <address@hidden> wrote:
I’m guessing that you’re hooking up Synth::seq_callback via fluid_sequencer_register_client or similar.

It seems like a bad idea to be attempting GUI operations from such a callback, as GUI APIs generally expect to be driven by a single thread. A quick search suggests that SDL’s convention is that only the thread which creates the main windows is allowed to access it.

Probably fluidsynth has its own separate thread to drive the midi sequencer resulting in this rule being violated, which could have many unpredictable consequences.

I don’t know if there are other conventions governing what sort of functions are “allowed” to be called from a fluidsynth callback, but my instinct here would be that you shouldn’t be doing anything that might block for i/o or to allocate memory or any other operation which might hold up the midi thread.

The usual workaround is to have the callback post an event to be handled by some other thread. The details of how to accomplish that vary from platform to platform; for windows PostMessage is a fairly simple way to get an event to the thread responsible for the GUI. SDL might provide something more portable?


On 19 Nov 2018, at 13:32, Paul Cohn <address@hidden> wrote:


I've been stuck on this bug for a little while now, and I'm not sure it's directly related to fluidsynth but I'm hoping someone can shed some light even if it's a basic C++ issue.

For context, I have a 2d game map you can move around, The effects of the bug I'm seeing are that the screen goes almost entirely black where it should be rendering stuff, except for the very top of the screen which shows what should be at the bottom of the screen, as if the camera has moved almost all the way down. I've checked and I believe the camera/map rendering is acting correctly.

This happens only when calling certain SDL functions from the sequencer callback, at the very least I've found it happens with SDL_DestroyTexture and SDL_CreateTextureFromSurface.

I have a Synth class that has a static seq_callback member. After playing something through the sequencer I need to trigger some effects, like showing a dialog. I have a reference to the Dialog class set on the Synth class as a static variable (since the static seq_callback needs to access it), and the dialog does stuff that ends up calling those SDL functions to display text.


class Dialog {
  showDialog() {
    // update label with text
    // this calls SDL_DestroyTexture / SDL_CreateTextureFromSurface

class Synth {
  static Dialog* dialog;
  static void seq_callback(...);

void Synth::seq_callback(...) {
  dialog->showDialog("Text!"); // this succeeds, but creates the black screen bug

I've tried triggering the dialog from other static functions in the same class and it seems to work fine, the only way I've been able to reproduce is by triggering calls to those SDL functions from the sequencer callback.

I am using:
OSX mojave
fluidsynth 1.11.1 (using brew, haven't been able to upgrade)
SDL 2.0.8 (also brew)

I think this actually used to work fine and am wondering if it's due to the mojave upgrade (which introduced a different kind of black screen bug), but it still seems strange that it only happens when triggered from the callback.

Any help would be greatly appreciated.


Paul Cohn

fluid-dev mailing list
fluid-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]