Hello everyone, I'm the creator of a game engine project which too relies on fluidsynth for handling midi sound rendering. From what I have gathered, my use of the library is similar in nature to that of ScummVM, because I only feed already parsed events into a synth object, and call synth_write to fetch the rendered samples into my buffer, which are then fed into the common audio pipeline (ie. fluidsynth interaction ends at this point). On the side of fluidsynth, there is theoretically no threading needed for just this rendering.
>From what I can tell, all the threading related glib usage of fluidsynth exists due to the code for running an actual "midi server", which continually accepts and renders events, and then feeds them into self-written audio backends in a threaded fashion. Only data structures like hashes are used for actual rendering purposes. I'm not super familiar with the codebase of fluidsynth, but would it perhaps be feasible to separate the sample rendering code out into it's own, almost glib-free sublibrary, which the rest of the codebase then uses? I think this way, both my engine and ScummVM could use only this sublibrary, and getting around the use of glib data structures should be a lot easier since they aren't platform-dependent. Currently, I always end up using an old fluidsynth version which predates the introduction of the glib dependency precisely because it's such a headache to build on eg. Win32 platforms. Thanks, Jonas 2016-01-14 0:32 GMT+01:00 Element Green <elem...@elementsofsound.org>: > Indeed. Probably the easiest would be to just lift the related bits from > glib itself. > > Best regards, > > Element > > > On Wed, Jan 13, 2016 at 4:29 PM, Ryan Gonzalez <rym...@gmail.com> wrote: > >> May I try? :D >> >> Pretty much everything outside of threading is really trivial. The wiki >> says the supported platforms are Windows, OSX, and Linux, and that it runs >> under Solaris and OS/2 but they aren't officially supported. >> >> For atomics, glib seems to use GCC's C++11-style atomics. when it can, >> then it falls back to either GCC/Clang's built-in __sync atomic operations >> or Windows's atomic API. >> >> For normal threads, glib uses pthreads on Posix and Windows threads >> on...Windows. >> >> Maybe I'm just super nerdy, but this seems totally doable. ;) >> >> On Wed, Jan 13, 2016 at 5:06 PM, Element Green < >> elem...@elementsofsound.org> wrote: >> >>> I think the ticket system on SourceForge would be the best way to submit >>> this: >>> https://sourceforge.net/p/fluidsynth/tickets/ >>> >>> Indeed, there isn't a lot of stuff that needs to be implemented to >>> remove glib as a dependency, for a single platform/architecture. Doing >>> this in a clean and portable fashion however, leads one back to glib. So >>> the way I could see this working would be to have native support for >>> certain key architectures which gets optionally selected at compile time >>> which causes a platform specific header and C file to be built (the stuff >>> in fluid_sys.[ch]) which supplies the needed macros and functions. In >>> order to do things properly, threading APIs like pthreads or Windows >>> related thread functions would need to be used (depending on the >>> platform). Some of the atomic operations may require assembler (a lot of >>> this can probably get lifted from glib), which ends up being compiler >>> specific. It may simplify things to only have libfluidsynth get built in >>> these cases and leave out the fluidsynth executable. That may cut down on >>> some of the platform support that needs to be implemented. >>> >>> I'm not really available at this time to assist with any of this, so >>> hopefully some other developer will step up and help integrate such patches. >>> >>> Best regards, >>> >>> Element >>> >>> >>> >>> >>> On Wed, Jan 13, 2016 at 2:06 PM, Ryan Gonzalez <rym...@gmail.com> wrote: >>> >>>> Well, the majority of g_* are wrapped with macros anyway, so it >>>> wouldn't be a major issue. >>>> >>>> Would the developers of Fluidsynth be OK if I sent a series of patches >>>> to this list that slowly eliminated the need for glib? Unless you have >>>> another way of handling contributions or something.... >>>> >>>> On Wed, Jan 13, 2016 at 2:33 PM, Kjetil Matheussen < >>>> k.s.matheus...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Jan 13, 2016 at 9:28 PM, Ryan Gonzalez <rym...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Similar things for the rest of them. This doesn't seem TOO bad... >>>>>> >>>>>> >>>>> Maybe it would be a good idea to just implement the necessary >>>>> "g_"* functions for the needed platforms instead of creating a new API >>>>> doing all of these things? >>>>> >>>>> >>>>> _______________________________________________ >>>>> fluid-dev mailing list >>>>> fluid-dev@nongnu.org >>>>> https://lists.nongnu.org/mailman/listinfo/fluid-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> Ryan >>>> [ERROR]: Your autotools build scripts are 200 lines longer than your >>>> program. Something’s wrong. >>>> http://kirbyfan64.github.io/ >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> -- >> Ryan >> [ERROR]: Your autotools build scripts are 200 lines longer than your >> program. Something’s wrong. >> http://kirbyfan64.github.io/ >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
