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,
Josh
Quoting jimmy <wg20...@yahoo.com>:
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)?
Jimmy
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fluid-dev
