[LV2] Worker extension

Stefan Kersten sk at k-hornz.de
Fri Mar 23 03:46:50 PDT 2012


On 3/23/12 2:52 AM, David Robillard wrote:
> 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).

execution order of `run' and `work_response' shouldn't matter, right?

> 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.

i think this would unnecessarily complicate the interface without much 
benefit.

> 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.

i will definitely need something like this at some point and the 
extension looks very workable to me (sorry, cannot implement it right away).

the only thing i am missing is priorities; e.g. when streaming from 
disk, those messages could be made higher priority than other 
non-realtime messages or be actually sent to a higher priority worker 
thread. maybe the atom/message extension could be used to specify 
worker/scheduler metadata (like priorities) in an extensible way?

<sk>



More information about the Devel mailing list