[LV2] Worker extension

David Robillard d at drobilla.net
Thu Mar 22 18:52:16 PDT 2012


The eg-sampler plugin has been serving as the canonical example of the
new stuff coming for LV2.  One obvious thing is that this plugin
launches a thread, and has ringbuffers and synchronisation primitives to
communicate with it.

Considering hosts that run many plugins, this seems like a very poor
situation, so I have been experimenting with finding the simplest
possible way to get non-realtime functionality without having every
plugin make a thread, and a bunch of "hopefully large enough" buffers,
etc.  This is it:

http://lv2plug.in/ns/ext/worker/worker.h

This is specifically designed so that the host can use one big
ringbuffer for many plugins, making the size limits a lot more flexible.
It is also designed to 'degrade' to single-threaded execution with
sample accuracy.

I have updated SVN so the eg-sampler plugin uses this instead.  There is
one pretty tricky aspect about this extension: if you want to write to
an output port as a result of some work (e.g. to notify the UI), you
have to do so in a callback other than run().  This means the host must
call the response callback *after* run, and can be a bit tricky from the
plugin POV.  It also doesn't jive with my opinion that it's is an error
for ports to be accessible outside run() at all (though of course this
is in the same context).

However, this is the only way to make things work sanely and
synchronously when freewheeling, that I can figure out.  The idea is
that, when running non-realtime, the work and responses will actually
execute immediately, which lets you do non-realtime things with sample
accuracy for offline rendering.  For example, if you switch samples at
frame 12, it will truly switch samples at frame 12, send a notification
about it at frame 12, and rendering past frame 12 will use the new
sample[1].  The same code will be real-time safe when running real-time,
however, you just lose the sample accuracy.

We could throw that out and have a call to actively fetch responses, so
you could do everything in run().  I am not sure if this would be
clearer, or worth the cost, and it kind of raises questions about where
you're going to actually read that data.

Opinions welcome.  It'd be useful if anyone planning to do non-realtime
stuff in plugins could skim this header and imagine implementing what
they need with it (or better yet, actually implementing it, it should
work in Jalv) and telling the list what comes up.

Thanks,

-dr

[1] Note eg-sampler doesn't actually implement this



More information about the Devel mailing list