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