avldrums.lv2 - DD upload

[Jaromír Mikeš]

2017-06-26 15:26 GMT+02:00 James Cowgill <jcowgill at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170626/9887450f/attachment-0001.html>