[Top][All Lists]

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

Re: [fluid-dev] New architecture is in place

From: Sven Meier
Subject: Re: [fluid-dev] New architecture is in place
Date: Thu, 01 Jul 2010 22:50:14 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100423 Thunderbird/3.0.4

Hi David,

I've just tested your changes here and can confirm that the reordering issues are fixed. I'm testing synth.threadsafe-api now to see whether it makes a noticable difference.

BTW does the new cmake based build work on Windows already?

Thanks for your efforts.


On 07/01/2010 02:05 PM, David Henningsson wrote:
I have just committed the changes to the fluid_synth class, which means
that the new architecture is in place. With that I hope that the
reordering issues (tickets #65, #76, #79) are gone for good.

There are two new settings controlling the thread safety,
synth.threadsafe-api and synth.parallel-render (I don't mind better name

synth.threadsafe-api controls whether the synth's public API is
protected by a mutex or not. Default is on, turn it off for slightly
better performance if you know you're only accessing the synth from one
thread only, this could be the case in many embedded use cases for
example. Fluidsynth executable can use many threads (shell is one, midi
driver is one, midi player is one) so you should usually leave it on.

synth.parallel-render is the low-latency setting. If on, you're allowed
to call fluid_synth_write_s16, fluid_synth_write_float,
fluid_synth_nwrite_float or fluid_synth_process in parallel with the
rest of the calls, and it won't be blocked by time intensive calls to
the synth. Turn it off if throughput is more important than latency, e g
in rendering-to-file scenarios where underruns is not an issue.

Some cleanup and testing remains, at least:

* Update autotools build system (currently CMake is updated)

* Go through fluid_synth_t and see what is currently atomic and shadowed
and what could be changed to ordinary variables

* See if there are other public API functions (apart from synth.h) which
should be mutex protected

* Move multi-thread rendering to the voice_mixer

* Revisit voice-stealing algorithm

* I've tried fast rendering and live keyboard playing, but many more use
cases remains to be tested, help is welcome!


// David

fluid-dev mailing list

reply via email to

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