[gmpi] Re: Topic 7: Audio packaging, Process-In-Place

> >>>
> Is that really that common that it is the sole reason to shoot down
> potential other wins?
> <<<
> 
> What we do today with splitters is have the plugin process the first output
> in place, and then allocate new buffers for all other outputs.  We don't
> attempt to determine whether or not output buffers are processed in-place
> downstream or not to try to save an extra buffer copy.  Must plugins are
> in-place, so it's simply more likely that a buffer copy will be needed.

In the Y split case, you can only share the input IFF no plugin writes to the 
buffer until all readers are done.

If you don't enforce ordering (except for producers/consumers, of course)
amongst plugins, they all have to have unique inputs.  If it is not enforced
as to which side of the Y runs first, you must memcpy() the buffer before
feeding it to the effect, right?  Then the effect can process-in-place or
not as it is told.

If you do enforce ordering, you can share inputs, and just force the one
that will overwrite the input to run last.

Which is more expensive?  copying the buffer or enforcing ordering?  Almost
certainly the buffer copy.

Baton-passing is not dead yet. With baton-passing, you can avoid the memcpy 
(which is the most expensive bit) by making all branches of a Y be
read-only.  Yes, you won't get process-in-place, but you have no extraneous
buffer copying.

Steve Harris wrote:

> > A light bulb did go on today when I realized the ordering issue.  Is this
> > actually a common case?  It seems the ONLY time this can happen is when the
> > host does a Y split.
> 
> It also makes things easier in general.

It's easier to understand at first.  I don't think it really makes any
significant difference (the devil may lurk in the details)

> > Is that really that common that it is the sole reason to shoot down
> > potential other wins?
> 
> No, I very much doubt the optimisations you would get form your solution
> would outweight the cost of handling it. Plus the (design) complexity of
> course.

The cost of baton passing:

* in process():

  struct buffer *ins[N_INS];
  struct buffer *outs[N_OUTS];

  host->give_me_my_inputs(ins);
  /* do my stuff, populate outs[] */
  /* for each input either reuse it, or call host->release_buffer() on it */
  host->here_are_my_outputs(outs);

Pretty low cost.  Both in complexity and in actual code.  Like I said, the
wins from baton-passing are reduced complexity in the host (no flags, no
worries about ordering, or what can be reused where), 0-cost format
converters as GMPI plugins (no host specific tricks needed), and possible
in-place processing for plugins which can't adhere to the 'simple' rules.
It also gives us an avenue to do some interesting things in the future,
perhaps.

Afterall, in-place-processing is designed to lower memory usage.  You still
have a RMW cycle on every sample, so (nominally) bandwith usage is the same.

I'm not saying it is the best answer, yet.  Just that the drawbacks are
slight.  I don't know if the upsides are really useful.



----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: