[fluid-dev] Re: Revert program change return event stuff

[David Henningsson]

address@hidden wrote:
> I think I will just revert the changes in regards to processing program 
> change events in the helper thread.  The problems with program changes
> occurring in the synth thread (possible mutex contention and memory 
> allocation) seem less of an issue in comparison and will only happen in 
> the case of MIDI events being generated in the synthesis thread.

Agreed.

> I did start thinking along the lines of making the program change 
> lock/malloc free.  Unfortunately the allocation of presets is left up to 
> the SoundFont loader.  But the internal SoundFont loaders could be 
> modified to assign each preset a pre-allocated fluid_preset_t structure, 
> so that it does not need to be allocated or freed during program 
> change.  In fact these structures could probably be shared for an entire 
> SoundFont.  This means that the get_preset method would be marked as a 
> real-time sensitive method.  Existing programs that use the SoundFont 
> loader would likely need to update this method, to remain real-time safe.

I haven't looked much into that piece of code, but if it is doable, it 
sounds like a good idea for the next version of FluidSynth.

> Any ideas how to have a lock free method of accessing the SoundFont 
> list, when searching for a preset? 

Reallocations of the list array is not a problem now that we have a max 
of 2048 soundfonts, we could just allocate a static list of 2048 
fluid_sfont_info_t records (and perhaps an atomic max-variable for 
optimization). Before searching a record we increase its refcount (which 
will have to be atomic), and decrease it when we're finished.

> A secondary shadow SoundFont list 
> owned by the synth thread, which is synchronized via the queue, might 
> work.  Seems slightly messy though and I know how much you hate those 
> shadow variables ;)

I had a second look at those shadow variables and decided not to dislike 
them. ;-) I don't see them as shadow variables though, for me they are 
the primary variables of the state machine, and the voice renderer keeps 
a copy of them for its own purposes.

> Maybe its not worth trying to fix now.

Well, I'm sure you know my standpoint on *that* one... ;-)

// David