Subject: RE: [linux-audio-dev] Re: A Plugin API
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ti helmi 29 2000 - 04:15:01 EST
Hmmm - my initial reply wasn't terribly intelligible was it. I'll try to
elaborate:
With the API as it is, one can only associate a port with a single buffer.
This means that if B:port1 is associated with buf1 by the host then buf1
will be used for both input *and* output, so a variant of case three in
your diagrams below happens, rather than case one. Case study in more
detail:
(1) A has single out port, B has *combined* in/out port, C has separate in
and out ports, D has separate in and out ports and the run ordering has to
be ABCD (for reasons not on the diagram). Looking just at the links
mediated by buf1, we have a variant of your third diagram in which you
agree there's an ordering problem. Both A and B write into buf1, so the
audio from A is overwritten before it reaches C. As far as I can see there
is no other way for the host to handle this linkage without buffer copying.
MN would certainly have difficulty with this.
A---->buf1---->B---->buf1---->D---->buf3
\
buf1
\
C---->buf2
(2) A has single out port, B has *separate* in and out ports, C has
separate in and out ports, D has separate in and out ports and the run
ordering has to be ABCD (for reasons not on the diagram). Here, although
buf1 appears more than once (A only writes to one place and no buffer
copying is used), there are no process ordering issues beyond those given
by the basic process linkage:
A---->buf1---->B---->buf2---->D---->buf4
\
buf1
\
C---->buf3
It's quite possible I'm missing the point on this, so please bear with me!
However, the position from my perspective at the moment is that at least
MN, and probably other (/all?) hosts will have to introduce some kind of
buffer copying algorithm to handle case 1 above. MN already has very
powerful (i.e. complex) flow logic/graph analysis and I'm not sure I really
want to do this. I'm rather hoping I'll get away with crying 'least common
denominator' and suggest we keep the ban on in/out ports - it will get MN
(and simpler hosts) out of a potential hole! Alternatively we could change
the API to allow specification of an in AND an out buffer for each port.
I'd be alright with this although I consider that additional complexity
that doesn't actually give any additional expressive power.
Hey - these problems are the kind of thing that motivated the coding of MN
in the first place - isn't this stuff fun ;)
Best wishes,
-- Richard
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST