Re: [fluid-dev] Qsynth broken with FluidSynth 1.1.0

[Rui Nuno Capela]

address@hidden wrote:
> 
> I notice that QSynth makes use of fluid_synth_get_channel_preset(). 
> There have been a number of thread safety issues with FluidSynth, many
> of which have been fixed in 1.1.0.  The issue with that particular
> function, is that presets are allocated when they are assigned to a
> channel and freed when another preset is assigned (a program change for
> example).  This means that currently there are no guarantees that the
> preset returned by fluid_synth_get_channel_preset() will be valid, in a
> multi-thread environment.
> 
> I'd like to resolve this issue.  The ideal solution would be to add
> reference counting to presets, but this would require an additional API
> function (fluid_synth_ref_channel_preset() and fluid_preset_unref() for
> example).  Another option would be to add a function to query the
> current preset info, without having to retrieve the preset, something like:
> fluid_synth_channel_preset_info (synth, chan, &name, &bank, &program);
> 
> Trying to get fluid_synth_get_channel_preset() to be thread safe, isn't
> so straightforward though, since there is no way for FluidSynth to know
> how long the calling application will access the preset.  Its documented
> as a "low level access" function, so I was considering just making it a
> function restricted to synthesis context (from a note-on method or in
> the audio driver) and providing other methods of safely retrieving the
> preset info.
> 
> By the way, this issue is nothing new.  Older versions of FluidSynth
> could potentially crash QSynth if a program change occurred at the right
> moment.
> 
> Any ideas or preferences?
> 

a variation of what you suggested would be fine,

fluid_preset_info_t info;
fluid_synth_get_channel_preset_info(synth, chan, &info);

seems to be a solution. the returned new struct fluid_preset_info_t
would have bank, num, name and sfont as public api accessible members.

then we could throw fluid_synth_get_channel_preset() into the deep low
deprecation abyss :)

cheers
-- 
rncbc aka Rui Nuno Capela
address@hidden