[gmpi] Re: 3.10 - Audio I/O
- From: Marc Poirier <fipnid@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sat, 20 Mar 2004 08:24:37 -0800 (PST)
This generally looks very good to me. I just have a few comments and
questions:
> 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.
> 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.
> 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,
or something like that. I really would like to see us not do that but
have it so that a plugin either does in-place or non-in-place and that's
all. However, I will also say that I don't understand (aside from
mis-matched numbers of i/o) why some hosts really want to do non-in-place
processing and if having to do in-place processing will really pose a
problem to some hosts. If so, I'd like to understand about that. If not,
then I say that plugins should only have to support one or the other.
Marc
__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html
----------------------------------------------------------------------
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
- Follow-Ups:
- [gmpi] Re: 3.10 - Audio I/O
- From: Steve Harris
- [gmpi] Re: 3.10 - Audio I/O
- From: Mike Berry
- [gmpi] Re: 3.10 - Audio I/O
- From: Tim Hockin
- References:
- [gmpi] 3.10 - Audio I/O
- From: Tim Hockin
Other related posts:
- » [gmpi] 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- » [gmpi] Re: 3.10 - Audio I/O
- [gmpi] Re: 3.10 - Audio I/O
- From: Steve Harris
- [gmpi] Re: 3.10 - Audio I/O
- From: Mike Berry
- [gmpi] Re: 3.10 - Audio I/O
- From: Tim Hockin
- [gmpi] 3.10 - Audio I/O
- From: Tim Hockin