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 <lordh...@gmail.com
<mailto:lordh...@gmail.com>> 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
fluid-dev@nongnu.org <mailto:fluid-dev@nongnu.org>
https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
