Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts

[Ceresa Jean-Jacques]

> 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." <address@hidden>
> > A : address@hidden
> > Copie à : "Marcus Weseloh" <address@hidden>, "Ceresa Jean-Jacques" <address@hidden>
> > 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
> >