[Top][All Lists]

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

Re: [fluid-dev] Thread safety

From: josh
Subject: Re: [fluid-dev] Thread safety
Date: Wed, 20 May 2009 13:49:28 -0400
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Hello Jimmy,

The current design of FluidSynth is that the synthesizer runs in the audio thread, there is a MIDI thread and the main thread for the fluidsynth shell. The audio thread synthesizes active voices to the audio stream. Events received by the MIDI thread activate/deactivate voices based on note on/off events and change voice parameters via controllers, etc.

Currently there exist mutual exclusion issues between threads which create MIDI events and the synthesizer thread. Either proper mutex locking needs to be implemented or the code must be serialized in a way, where locking is not needed. What David is proposing is the latter.

The only real parallel execution benefit that FluidSynth currently has, is that calculations related to incoming MIDI events occur in parallel with the audio synthesis processing. If all this could occur in one thread and the MIDI events could be processed while waiting for the next playback audio buffer to be ready, then David's proposed single thread synthesis architecture may actually be more efficient on a single CPU system. I think this may be hard to do though, since the various execution models of the audio drivers (Jack versus ALSA for example), make it difficult to process the MIDI events while waiting for the next audio buffer "fill" event.

These changes should not affect functionality as seen by external software using FluidSynth. At least that is the goal. So rest assured, that whatever final resolution we choose, FluidSynth should be more stable, with a minimal amount of added overhead (if any).

Best regards,


Quoting jimmy <address@hidden>:

Some more questions for David,

I don't know of the FS internal threading code or David's propose changes. But let me ask if the change may affect apps that use 32, 48, 64, or more channels? There are some apps that use such features in FS.

Along with that, what about cases of running multiple apps and multiple hardware sequence players (drum machine, background sequences, and midi keyboards... at the same time) that connect through jackd to FS playing in live (in real time, low-latency)?


fluid-dev mailing list

reply via email to

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