> Let me just clarify: As of 1.1.7 audio rendering does not lock any mutex.
Thanks for recalling this and the use of "synth.parallel-render" to true to
avoid audio rendering API locking the mutex.
>The worst-case scenario that I currently see is that it would block/delay
>incoming midi events because they're dispatched immediately to
>fluid_synth_handle_midi_event().
So now for the "lazy loading", the only potential real time dependancy is
between MIDI events API and the future "smart" preset loading API (i guest
somes new API will appears).
This should not be an issue for MIDI driver that works by interrupt because in
this case, if the mutex is locked, as it is recursive and the calling task is
the same the mutex will not block.
Unfortunatelly this behaviour is not only OS specific but also MIDI Driver
developper dependent . In all cases if Marcus need any feedback to verify any
works in progress on Windows don't hesitate to ask.
jjc
> Message du 06/04/18 17:49
> De : "Tom M."
> A : fluid-dev@nongnu.org
> Copie à : "Marcus Weseloh" , "Ceresa Jean-Jacques"
> Objet : Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts
>
> Let me just clarify: As of 1.1.7 audio rendering does not lock any mutex.
> Previously, you had the option to set "synth.parallel-render" to false,
> causing any thread attempting to enter fluid_synth_write_*() to acquire the
> lock. However, this caused bug #192, because the current synthesization
> implementation is generally not capable of this "functionality" and therefore
> I hard coded "synth.parallel-render" to true. Which is the default and better
> anyway, as it does not block.
>
> @JJC: regarding your partitioning of the synth API: you're broadly correct.
> The problem is, how to treat program change and program select events? On the
> one hand they change midi related stuff, on the other they get down to the
> soundfont loader. Given that, I think for now it is correct to only have one
> mutex locking the synth.
>
> @Marcus: I basically like the idea of doing the **smart** sample loading
> under the API lock. The worst-case scenario that I currently see is that it
> would block/delay incoming midi events because they're dispatched immediately
> to fluid_synth_handle_midi_event(). For the midi_player this would only
> matter in system clock mode. And for jack for instance this would mean we're
> endanger to be kicked from the callback cycle (which is strictly speaking bug
> #79 though)... well low latency audio and smart sample loading are hard to
> befriend I guess. Nevertheless I think we should give it a try, esp. due to
> the simple implementation.
>
>
> Tom
>
_______________________________________________
fluid-dev mailing list
fluid-dev@nongnu.org
https://lists.nongnu.org/mailman/listinfo/fluid-dev
