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

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Wed, 28 May 2003 15:39:33 -0700 (PDT)

> Hasn't the proposal info been spread among many posts?  Could you 
> pull together a summary/overview for folks to evaluate, Tim?

fair enough.


At start time, the host pre-allocates a pool of buffers (perhaps 1 buffer for
each output in the graph or figure out the max possible at any given time,
or some heuristic).

The host also sets up each output -> input connection with a pointer to a
buffer (actually a 'struct buffer **' or something).

The host starts with sources.  The sources ask the host for any buffers they
need (one for each output).  They generate sound into the buffers.  They
then write the buffer (struct buffer * actually) to their output pointer:

at connection:
        /* plug-global */
        struct buffer **output[N_OUTPUTS];

        /* host sends one connection for each buffer */
        buffer[index] = output_ptr_from_host;


at process():
        /* get a buffer */
        buffer = host->new_buffer();

        /* process into it... */

        /* output it */
        *(output[index]) = buffer;

Once that is done, the source is done with the buffer.

Now for effects.  No effect can run until it's sources are done.  When an
effect->process() is called, all the outputs are done.  The effect reads
it's inputs:

        inbuffer = *(input[idx]);
        /* process in place */
        *(output[index]) = inbuffer;

or

        inbuffer = *(input[idx]);
        outbuffer = host->new_buffer();
        /* process into outbuffer */
        *(output[index]) = outbuffer;
        host->free_buffer(inbuffer);


The only cost is the indirection which is done once for each input or
output, and the buffer management calls, which should be CHEAP.

> communicate back & forth at buffer setup time, i.e. arrive at a total 
> number of actual buffers needed and get the input pointers straight, 
> and then agree on the output pointers. Could you include an example 
> or two of that?

That can be done wither with heuristics (the host knows the widest point in
any signal chain wrt # of channels) or more formally - after connecting, ask
each plugin how many more buffers it will need.  I don't know if we want to
allow this to change dynamically or not.

Does that answer questions?  the pointer bits can be SDK code, or typedefed
or macro'ed away for those people who don't grok pointers.

I've dubbed it 'baton passing' because each pluging hands the buffers to the
next plugin, like a relay-race.

The upsides:
* plugins can process in-place or not, and the host doesn't care, even for
very odd mappings
* plugins can swap pointers if they want, the host doesn't care
* format converters are now basically free

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