[Top][All Lists]

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

Re: [fluid-dev] Crash caused by hot-plugging audio

From: josh
Subject: Re: [fluid-dev] Crash caused by hot-plugging audio
Date: Tue, 10 Nov 2009 17:29:15 -0800
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Hello Ebrahim,

Quoting Ebrahim Mayat <address@hidden>:
Hello all

I happened to stumble upon a way to make the new fluidsynth crash.
This is a minor bug which I can live with but I'll report it anyway.

Fluidsynth can be launched and executed to obtain audio output from my
computer's speakers. But when I try to patch the computer's audio
output socket with an audio mixer's input socket, I get the following

** (process:532): CRITICAL **: fluid_synth_alloc_voice: assertion `fluid_synth_is_synth_thread (synth)' failed

Secondly, if the audio ports are patched beforehand and fluidsynth is
run, there is no problem injecting MIDI-triggered audio into the mixer
but if the plug is then pulled from the computer's audio out, the same
error occurs.

Thirdly, there is no problem with audio hot-plugging if I run qsynth
linked to fluidsynth-1.0.9.

(All this was done on OS X by the way.)


Uhh oh. This sounds like the audio driver starts to get called by another thread, than the original audio thread. I was afraid that might happen and I'm not exactly certain how to resolve it with the current architecture. Many FluidSynth functions attempt to determine whether they are being called from synthesis thread context or not. Right now the method of detecting this, is to assume the first thread to call the audio synthesis routines is the audio synthesis thread. If another thread gets used afterwards, then that is a problem. I'll have to think about this one a bit. I'm curious why it is happening, but I can see that it may also possibly occur with Jack as well, since FluidSynth doesn't actually create or control the audio thread in that case.

For that particular function (fluid_synth_alloc_voice) I could remove the assertion that it is the synthesis thread, though that could also mask potential threading issues in an application using FluidSynth. A check could also be done in the synthesis functions to see if the calling thread has changed.

If anyone has any better ideas of how to handle this with the current FluidSynth API, I'm all ears!


reply via email to

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