Re: [fluid-dev] Time to release?

[josh]

Quoting David Henningsson <address@hidden>:
> I've just committed a small patch which updates the synthesis thread
> variable at every call to fluid_synth_one_block, which should fix
> Ebrahim's thread-jumping problem. Assuming Ebrahim confirms that it is
> fixed, perhaps it is time to release a bugfixed version? Josh, do you
> agree?

I think I may have beat you too it!  I also committed this same patch  
and didn't see any other changes at the time I committed it.  I hope  
the call to get the thread ID isn't much overhead.  The reason I only  
checked it once before, was for that reason.

Its not ready yet.  I've still got 3 items to resolve:

1. Querying a preset or its info, should provide the most recently  
assigned preset.  Queuing breaks this currently.

2. Allocating a preset (fluid_synth_get_preset,  
fluid_synth_get_preset_by_sfont_name and fluid_synth_find_preset)  
require mutex locks.  This means they should not be called from  
synthesis context, but currently are!

3. Provide API to get information about a preset on a given channel,  
as discussed with Rui.


#3 should be fairly trivial, once #1 is solved.  If you have any ideas  
for #1 and #2, that would probably be helpful.

Ideas for #1 and #3, allocating and freeing a preset is done under  
mutex lock (well freeing currently isn't, but it could be made to be  
so).  Each channel could then have a shadow_preset field, which gets  
assigned the most recent preset also under mutex lock.  Preset  
assignments are still queued to the synthesis thread and return queued  
for freeing.  Getting info on a channel preset could then just hold  
the mutex also, while copying the info.  The  
fluid_synth_get_channel_preset() would then just be for within  
synthesis context and/or deprecated.

I'm not yet sure how to solve #2.  If a bank/program change occurs in  
a high priority MIDI thread (which could be even the audio thread in  
the case of Jack), holding a mutex to find a preset is a bad idea.   
I'm also not sure how to signal a lower priority worker thread,  
without a mutex.  Any ideas?  If the return queue could be signaled  
and woken up, without a mutex, that would probably be the right way to  
handle it.  g_cond is supposed to use g_mutexes though, to protect the  
condition (event count for example).

Many of the recent changes I made, have to do with making synth query  
functions return the most recent value, regardless if it has actually  
been assigned in the synthesis thread or not.  I did my best to think  
through any sort of out of order processing that could occur in  
regards to queuing and non-queuing and didn't see any obvious issues.   
But I'm not completely confident on this.


> Or are there any volonteers planning to test the new FluidSynth version
> before we release it? In Ubuntu, there is at least fluidsynth-dssi and
> tuxguitar, which would be nice if someone volonteered to test.
>
> // David


Do you want to do an RC release this time?  1.1.1-RC1?  It would be  
good to get something out soon, before people start using the  
semi-busted 1.1.0, at least in regards to QSynth compatibility.

Josh