Ebrahim Mayat wrote:
Currently, fluidsynth has five threads.
5 process 6014 thread 0x6f03 0x936a11f8 in mach_msg_trap ()
4 process 6014 thread 0x6703 0x936a1278 in
semaphore_timedwait_signal_trap ()
3 process 6014 thread 0x6203 0x936a11f8 in mach_msg_trap ()
2 process 6014 thread 0x1003 0x936a7c0c in __semwait_signal ()
* 1 process 6014 thread 0x10b 0x936ae6b8 in read$UNIX2003 ()
Of these threads the shell process (fluidsynth.c) is the first one. The
second thread begins with fluid_synth_return_event_process_thread which
together with fluid_synth_one_block are declared in fluid_synth.c
The other three threads (please correct me if I am wrong) address the
audio, MIDI and I/O procs.
How does the state machine and voice renderer fit into this picture ?
Hi Ebrahim and thanks for the thread overview; it's nice to have that
point of view as well.
A difference between 1.0.9 and 1.1.0 is that the audio thread got more
of the state machine work to do; making it harder to keep its real-time
properties. I admit to not having considered this well enough when we
discussed the thread safety the previous time.
So I want to give the audio thread as little to do as possible, to make
it as easy as possible to avoid xruns. The audio thread is proposed to
do just the voice renderer work, not the state machine work (which it
does in 1.1.0).
The midi thread and shell threads will do the state machine work, when
they make calls against the fluid_synth object.
The return event queue thread is mainly used for garbage collection,
when the audio thread leaves garbage behind that cannot be collected
within a fixed enough time. Hopefully it can be removed if the audio
thread gets less to do, but I'm not certain about this.
I'm not sure about the fifth (I/O procs) thread, is that something used
internally by libraries we use? What does it do?
// David
_______________________________________________
fluid-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/fluid-dev
