Re: [fluid-dev] FluidSynth and glib

[Johannes Schickel]

Hi Element,

don't worry, I see the point of using glib from your side. :-)

You seem to be right about the hash table code. It looks like it only 
mentions "g_hashtable" in some comments, I appareantly missed that when 
giving this a quick grep run earlier. Ooops :-).

I was looking a bit into the (obvious) glib dependencies. And yeah, it 
looks most is threading related.
It looks like the synthesizer code has support for multi-threaded 
rendering. I.e. there seems to be referrences to 
"fluid_rvoice_mixer_set_threads", which uses "new_fluid_thread". I guess 
one could strip that out though.
Then there is this very odd timer use (which uses a thread internally) 
in src/synth/fluid_synth.c:3182, which seems to start a new timer to 
unload a sound font in case unloading failed. I am not sure how you 
would work around that.
The only non-thread related glib reference I can find right now is 
FLUID_DECLARE_VLA, which falls back to glib's g_newa in case no VLAs are 
supported by the compiler.

One sad thing is: multi-threaded rendering might be interesting for some 
platforms we support. A lot of smartphones etc. nowadays feature 
multiple cores, so taking advantage might be something to look into.

I initially hoped the synthesizer in FluidSynth would be easily working 
without glib as dependency. But it looks like that is not the case :-/. 
And I really don't want to make use of a patched up FluidSynth. So 
unless there is hope any such work could get back upstream, it is not an 
option.

Thank you for your insights.

Best regards,
Johannes

On 01/13/2016 06:36 PM, Element Green wrote:
> Hello Johannes,
>
> Seeing as I'm the one responsible for converting FluidSynth over to 
> glib in the first place, I thought it is only right that I respond ;-)
>
> Prior to FluidSynth depending on glib, there was a bit of platform 
> support code.  This code was error prone, somewhat hard to maintain, 
> and often limited supported platforms. Leveraging off of glib meant 
> that all of this code could be removed and FluidSynth would 
> automatically be available on any platform glib supports.  So this was 
> primarily a convenience for developers.
>
> However, there are cases where it would be nice to not have this 
> dependency.  Embedded and mobile systems use is one example in 
> addition to the Windows use case you describe. However, from what I 
> have gathered, there are versions of glib that do support Win9x which 
> also meet the minimum required version for FluidSynth.  FluidSynth 
> currently depends on glib 2.6.5+.  This email thread 
> (http://gtk.10911.n7.nabble.com/Last-supported-version-of-GTK-for-Win9x-ME-td57072.html) 
> suggests that glib supported win9x with versions as late as 2.6.10 at 
> least (though it is actually talking about GTK in this case - which 
> glib is a dependency of).
>
> Having said all that, it would be nice to have the ability to build a 
> possibly stripped down version of FluidSynth which would utilize a 
> user defined compatibility layer.  I did a quick glance at the current 
> source code.  From what I an tell, the hash table code is native to 
> FluidSynth and was lifted from glib sources.  The majority of the glib 
> subsystem use is related to thread creation/management, thread locking 
> primitives, thread signaling, thread private data, and atomic data 
> operations.  For the single thread use case, a lot of this code is not 
> needed.  Internally the FluidSynth source code still has it's own 
> compatibility layer and from what I can see does not reference glib 
> directly.  The majority of this interface is defined in 
> utils/fluid_sys.c and utils/fluid_sys.h.  Defining platform specific 
> versions of these files would provide what I think you are seeking.  A 
> lot of those primitives are fairly simple really, and could probably 
> be easily lifted from glib sources for use on a specific platform.
>
> At any rate, seems like a good idea.  It would take a little work though.
>
> Best regards,
>
> Element
>
>
>
> On Wed, Jan 13, 2016 at 6:52 AM, Johannes Schickel <address@hidden 
> <mailto:address@hidden>> wrote:
>
>     Hello,
>
>     first of all thank you for your awesome project!
>
>     I am a member of ScummVM (http://www.scummvm.org) and I am
>     currently looking into getting our FluidSynth support a bit more
>     up to speed (i.e. get it into more of our ports, updating to the
>     latest version, etc). It looks like there are some obstacles for
>     this though. The biggest one is the glib dependency. For example,
>     modern glib versions do not support Win9x anymore (2.6.9 is the
>     last one to support this AFAICT from:
>     http://gtk-win.sourceforge.net/home/index.php/Main/Downloads),
>     which is some target we still support.
>
>     >From a quick look at FluidSynth I have the feeling libfluidsynth
>     includes a lot of code we are not interested in for ScummVM. We
>     are only really interested in the actual synthesizer part. I hoped
>     this part would not depend on glib, however I found references to
>     glib's hash table and thread code. Is there any chance for the
>     future that FluidSynth's core synthesizer could be built
>     standalone and without glib dependency? This would allow us to
>     switch to a version more up to date than FluidSynth 1.0.9.
>
>     Thanks,
>     Johannes
>
>     _______________________________________________
>     fluid-dev mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.nongnu.org/mailman/listinfo/fluid-dev
>
>
>
>
> _______________________________________________
> fluid-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/fluid-dev