|
| From: | Ryan Gonzalez |
| Subject: | Re: [fluid-dev] FluidSynth and glib |
| Date: | Wed, 13 Jan 2016 14:28:22 -0600 |
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
_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev
| [Prev in Thread] | Current Thread | [Next in Thread] |