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

  • From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 28 May 2003 04:30:41 -0700

Jeff said: 

re: process-in-place discussion....
...
Summary:
*Plugin can advertize it's ability to process-in-place. It's optional for
the plugin.
*Host can choose to honor the request or not. It's optional for the host
too.

Good summary. I would go on to add something like the following:

* At process() time, plugin gets all input and output buffer ptrs from host, which reflect host's final decisions about whether to honor the process-in-place requests (to conserve buffers) or not (simpler graph mgmt for the host).


I really like that process-in-place support can be optional for both host
and plugin, without compatibility probs.

Yes, the can-process-in place info that passes to the host really is just a hint about the inner structure of the plug's DSP code, to help the host optimize in case it's both capable of doing that (as gated by upstream/downstream connections, its own intelligence wrt graph construction/analysis, and available memory) and interested in doing that (with lots of memory and a new codebase, the host author might not care about saving memory).


Other questions:
Does process-in-place apply to:
A) all a plugin's pins?.....or
B) specify buffer sharing at granularity of individual pin pairs?

B is more powerfull, but I guess option-A would be fine for most plugins.
(gotta ignore those seductive 'corner cases'.....sirens luring us toward the
rocks!......)

I'm tempted to say that to have a general solution you'd need to do it at the per-buffer level, independent of any multichannel format buffer groupings. Of course the potential for unconnected inputs (per the other part of this thread) complicates the decision logic a bit for the host... but then again if it gets too tricky for a given connection the host can always just punt, and blow another buffer for that situation. We don't have to provide the host with foolproof optimized decision logic for every case, just a consistent/workable framework to optimize where it can.

-- Chris

----------------------------------------------------------------------
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 05-2003