[LAD] LV2 realtime safe memory pool extension

[David Olofson]

On Tuesday 13 November 2007, Lars Luthman wrote:
> On Tue, 2007-11-13 at 15:52 +0000, Krzysztof Foltman wrote:
> > One more thing - is there any way to communicate lack of data on
> > an audio port? For example, a synth with no note plugin could
> > communicate the fact that it produced a buffer full of zeros to
> > the following plugins, so they don't process those zeros
> > unnecessarily? 
> 
> No. It sounds very similar to the input-parameter-has-changed
> thing

Yes, they're very similar as long as control events and audio buffers 
alike are only "one per run() call". With timestamped events, they 
start to drift apart, I think.


> - maybe both could be solved by defining a new port class 
> whose buffer pointer points to a bitmask large enough to hold one
> bit for each plugin port, and using that to indicate when something
> has "happened" at a port (where the definition of a "happening"
> depends on the port class) ?

Similarly, when using timestamped control events, both features can be 
implemented that way - or rather, control events *are* "control 
changed" notifications (no extra logic needed), and some standardized 
control could be used to provide info on whether or not there is 
audio on audio ports.

However, it's not just about flags, unless all plugins are to be 
*required* to support silence. If you're sending to an input that 
doesn't care about silence, that input will need a zeroed out buffer, 
whereas an input that understands silence won't touch the buffer if 
it's known to be silent.


> There also are extensions in development (I think) that only call
> plugin callbacks if there actually is relevant input, but I think
> that was more for message passing and things like that.

That's a whole lot more complicated than it may sound at first. 
Whether or not a plugin needs to run can depend on a lot more than 
just whether or not it has input. Pretty much every effect (even 
filters) has a tail of some sort, so even in the simplest cases, 
you'd still have to ask the plugin when it's safe to *stop* calling 
it. Then you might get away with just waiting for input before 
starting it again, but I'm not sure that covers everything...

Besides, I don't think it buys us much having this level 
of "intelligence" in the API. All you can save is a function call, 
but to do that, the host needs to check a bunch of ports for data. I 
think the only sensible solution is to make it possible for plugins 
to generate and receive silent buffers, and let the plugins deal with 
that optimally - or not at all.

How about something like this:
	* A "Buffer" is an object with some flags, a
	  read-only (host managed) pointer to an actual
	  audio buffer, and a pointer that is managed
	  by the connected output port.
	* Buffers can be marked "SILENT" somehow.
	* Output ports that support this should set the
	  SILENT flag and point the Buffer at a host
	  provided silent buffer or equivalent, when
	  the output is silent. When there is sound, the
	  flag is removed and the pointer is reset to
	  the value of that read-only pointer.
	* Input ports that care about this can look
	  for the SILENT flag.


> > Sure, it's not trivial to set that flag correctly in plugins that
> > deal with any kind of internal state (especially complex one like
> > in reverb), but it worked very well for Buzz. The end result was
> > the ability to use very complex processing networks - as long as
> > not all instruments produced sound all the time.
> 
> This definitely sounds very useful.

It is, but the decision should go with the state - that is, inside the 
plugin. Simpler, cleaner and more efficient, I think.  The API (or 
host, as applicable) should only provide means for plugins to 
communicate the required information.

It appears that this would suggest moving complexity into plugins, but 
if this is to do much good, I think that's actually the easier way... 
Besides, people spend countless hours optimising code, writing SIMD 
code etc. Why not spend a fraction of that time implementing a 
relatively speaking trivial optimization like this?

[...]


//David Olofson - Programmer, Composer, Open Source Advocate

.-------  http://olofson.net - Games, SDL examples  -------.
|        http://zeespace.net - 2.5D rendering engine       |
|       http://audiality.org - Music/audio engine          |
|     http://eel.olofson.net - Real time scripting         |
'--  http://www.reologica.se - Rheology instrumentation  --'