<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-06-26 15:26 GMT+02:00 James Cowgill <span dir="ltr"><<a href="mailto:jcowgill@debian.org" target="_blank">jcowgill@debian.org</a>></span>:<br><div> <span class=""><br></span></div><div><span class="">Hi James,<br></span></div><div><span class="">for this topic I don't have enough arguments neither from debian policy neither from coding knowledge :(<br></span></div><div><span class="">I am copying Robin (upstream author) and I hope he will advocate his approach better than me. <br></span></div><div><span class=""><br></span></div><div><span class=""><br></span><span class=""></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> I have discussed this with upstream before ...<br>
> here is answer ... (  same might go for robtk? )<br>
> ------------------<br>
><br>
>> Is there some way use rather system-wide fluidsynth lib?<br>
><br>
> No (same with Ardour btw). It's a stripped down and patched dedicated<br>
> version and statically linked with hidden symbols.<br>
><br>
> Pro Audio Plugins should be self-contained and not rely on any system<br>
> libs except for libc (and libX11/xcb which needs to match the X11 server<br>
> ABI).<br>
><br>
> There are too many things that can go wrong otherwise (calf is the prime<br>
> example). e.g. update fftw or mix some random pango/cairo/pixman or even<br>
> just freetype version and you'll throw thread safety out of the window.<br>
> Any lib that uses a lock to maintain some global cache will void<br>
> realtime safety as well.  default fluidsynth falls in that category as<br>
> well:  .sf2 files are cached globally and a lock is used.<br>
><br>
> Remember, plugins are loaded in the same memory space as the host, which<br>
> may also use those libs. They're not standalone process separated apps.<br>
> Ideally plugins are self-contained and don't share any libs with the host.<br>
><br>
> If 2 unrelated plugins were to use the same shared libfludsynth various<br>
> edge cases can happen since the plugins don't know about each other.<br>
><br>
> Also related is exception handling in this case (setjmp/longjmp). At<br>
> least for rolling distros (e.g. debian/testing) where a library can be<br>
> compiled with a different compiler version than the plugin and host.<br>
> --------------<br>
<br>
</span>Unfortunately this isn't how Debian works. In my opinion it is<br>
unacceptable for avldrums.lv2 to be compiled against its own bundled<br>
version of freetype.<br>
<br>
WRT fluidsynth's real-time safety. Upstream may have a point here but<br>
from reading the fluidsynth source, it seems all the locks are not part<br>
of the global state, but part of the fluid_synth_t type. This should<br>
ensure that other plugins sharing fluidsynth cannot interfere with one<br>
another.<br>
<br>
I don't think the .sf2 cache is a very good point, since surely loading<br>
.sf2 files is not realtime anyway because it requires disk access? The<br>
fact that it uses a lock is insignificant.<br>
<br>
There is no use of setjmp / longjump in either avldrums or fluidsynth so<br>
that point is irrelevant (and I don't understand how compiler version<br>
would interfere with this anyway).<br>
<span class="HOEnZb"><font color="#888888"><br>
James</font></span></blockquote><div><br></div><div>best regards<br><br></div><div>mira <br></div></div></div></div>