Re: [LAD] LV2 realtime safe memory pool extension

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 --'
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Nov 14 00:15:02 2007