I think Tim's "baton passing" (I'd prefer "buffer passing") scheme seems
pretty good. I'd like it a bit better if it had read-only flags on the
input buffers that would force the plug to copy, well I think host writers
would prefer this.
One thing I like about it is that it forces us to confront issues that will
come up when dealing with non-PCM formats, or when dealing with plugs that
change the size of buffers due to sample rate conversion or time scale
modification. In these cases dynamic buffer allocation and buffer passing
seems to work better than having everything be pre-allocated by the host,
because the host doesn't know the output buffer sizes a priori.
Disadvantages are possible memory leak if plug forgets to free buffer (but
how hard is that?) and the requirement to be allocating during process (but
I think this is inevitable anyway).
Bill
At 03:39 PM 5/28/03 -0700, you wrote:
> 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
---------------------- Bill Gardner Wave Arts, Inc. 99 Mass. Ave., Arlington, MA 02474 Tel: 781-646-3794 Fax: 781-646-7190 billg@xxxxxxxxxxxx
---------------------------------------------------------------------- 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
