[gmpi] Re: 3.10 - Audio I/O

On Sat, Mar 20, 2004 at 08:24:37AM -0800, Marc Poirier wrote:
> > Req 40:   All connections between plugins are bundles of channels 
> > with defined relationships to each other (e.g. a mono stream is 
> > one channel, while a stereo stream is a left channel and a right 
> > channel, and a 5.1 stream is a bundle of left, right, center, 
> > surround-left, surround-right, and LFE channels).
> 
> I think that probably this is not the case, but just to make sure, does
> this at all preclude a plugin that does any arbitrary number of channels,
> but each one is a mono stream?  In other words, do all of the channels
> have to fit together into one conceptual "bundle" or can multi-mono be an
> option too?  I hope so, and I think so, but I wanted to check for sure.

Good point - there is nothing to suggest that a plugin can have more than
one input/output.  What if I changed Req 40 like:

Req 40:    All connections between plugins are bundles of channels with
defined relationships to each other (e.g. a mono stream is one channel,
while a stereo stream is a left channel and a right channel, and a 5.1
stream is a bundle of left, right, center, surround-left, surround-right,
and LFE channels).  A plugin may have any number of input or output
connections.

Or maybe split the last bit out on it's own?  Yes, I think it deserves to be
on it's own.  I also want to swap positions of 39 and 40.

> > Req 41:   Connections are handled atomically with respect to the 
> > bundle. All channels in a bundle are connected or disconnected 
> > together. Hosts may provide mechanisms for unbundling and 
> > re-bundling streams.
> 
> I'd like to hear more about what exactly this is supposed to mean.

If you have a 5.1 input, all 6 streams are connected. You can't just hook a
stereo output into a 5.1 input.

> > Req 42:   In-place processing (reusing an input buffer as an output 
> > buffer) must be supported by the API. If both the plugin and the 
> > host support in-place processing, it may be used. Hosts and plugins 
> > that do not support in-place processing must not need to do 
> > anything extra.
> 
> Something that I think has always been annoying about existing plugin APIs
> is how, if you support in-place processing, you still need to support
> non-in-place processing, too, and double your algorithm, or add branches,

We definitely need to avoid duplicate entry points like this.  I know we
talked a LOT about the various models and advantages thereof.  I don't want
to get bogged down in the details right now, as we don't need to decide an
implementation.

The simplest implementation would be something like the plugin announcing "I
am capable of in-place processing" or not (or flip it, make it announce its
incapability).  The host can set up the input/output buffers as it sees
fit.  Plugins would not need to know or care if they were running in-place
or not.

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