Re: [fluid-dev] More commits on the way to 1.1.1

[josh]

Just committed some more changes.

I think I resolved the return event queue issue.  Its now just a  
fluid_thread_t which uses a condition to get signaled when events are  
available.  fluid_synth_one_block() will signal the condition if there  
are any pending events in the return queue.  It does this without  
holding the mutex.  This means that there is the slight possibility  
that the return queue process could miss a signal, but it would just  
get signaled again in another call to fluid_synth_one_block().

Program change messages are queued in the return queue, if  
fluid_synth_program_change() is called in synthesis context.  This  
means that program changes cause an event to be sent to the return  
queue thread, which locates a matching preset, then an event gets sent  
back to the synthesis thread activating the preset.  Not exactly the  
most efficient, but I'm not sure how else to do it at the moment and  
program changes aren't really a common occurrence.

fluid_synth_cc() now always queues events for non-synthesis context  
(no more exceptions for certain events like bank selects).

fluid_synth_bank_select() and fluid_synth_sfont_select() also queue in  
non-synthesis context.


I made those additional changes to try and ensure that the queuing  
policy is identical across all events.  I realized there was another  
rather embarrassing bug related to event re-ordering of program change  
and other messages like MIDI system reset.  In the case of one MIDI  
file I tested, this resulted in all the presets getting reset after  
being assigned.  Hopefully there are no more such issues.

One thing I don't like about the program change return queue queuing,  
is that this will also occur when doing render to disk.  This could  
very well be an issue, since a significant amount of render time could  
pass before the return queue thread runs, which could lead to  
excessive stalls in processing program changes.  I'm not sure how to  
resolve this at the moment.  Perhaps we should review adding a runtime  
mechanism for turning off multi-threading, as we discussed previously.

The more I run into these types of issues, the more I'm beginning to  
agree, that this whole process of making FluidSynth more thread safe  
has been a bit rough.  I'm not sure how I would have done it  
differently though.  It seems like significant changes like these are  
bound to create some issues, especially since a lot of this last phase  
was getting used to the existing code base.  I think doing RC releases  
is a must though and will hopefully get more testing done prior to  
official releases.

I'm confident I can whip this thing into shape though, its just a  
matter of identifying any additional problem areas.  I think we are  
getting very close.  Its been a rather humbling experience indeed.

Josh