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

[josh]

Quoting David Henningsson <address@hidden>:

> 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.

Great!

> > 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.


You mean 1.1.1? ;)


> > 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.


True, or perhaps better would be a static array of fluid_sfont_t  
pointers.  Could do atomic compare and exchange operations on them or  
other such tricks, with an atomic integer count.


> > 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.


Your description is definitely more appropriate, but I couldn't think  
of another word to use other than shadow at the time.  Glad you don't  
dislike them anymore!


> > Maybe its not worth trying to fix now.
>
> Well, I'm sure you know my standpoint on *that* one... ;-)


Yes yes indeed.  Will release 1.1.1 real soon now :)  I'll just revert  
the program change stuff and we'll just have to live with some small  
holes in our real-time safety, but then only in certain cases.  Big  
deal.


> // David


Josh