Re: [linux-audio-dev] questions to be resolved

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] questions to be resolved
From: Vincent Touquet (vincent_AT_ulyssis.org)
Date: Mon May 21 2001 - 02:31:44 EEST


>1) what kind of object allocates and frees buffers used to store data
> for a port? is it something more like an engine object, or
> something more like a plugin? in LADSPA and VST, all buffers are
> owned by the host, and the plugins merely use them via their
> ports.
>
I would consider the buffers held by the LAAGA server (i.e. pointers to
shared memory defined in there).
So this LAAGA server acts as the host to the LADSPA plugins.
Abramo, is this consistent with your definition of soundbox ?
I'm sorry, I haven't had time to read up on your preliminary API.

>2) are buffers associated with input ports, output ports, both or neither?
>
As Tom pointed out, we could go with either input or output, both would
be overkill IMHO.

The options considering we want to minimize the number of buffers and
want *zerocopy* efficiency:

1) Go with one buffer per input and prohibit one out to multiple in (as
it makes you forced to hold an intermediary buffer, to be copied to the
various input ports: very inefficient)
2) Go with one buffer per output and prohibit multiple out to one in (as
this forces you again to merge those buffers into one)

Number one seems the most 'natural' to me.

>3) are multiple connections between ports allowed?
>
Mx1 *or* 1xN can be efficiently supported, but not both, at least if the
criteria are:
- minimizing buffers (reducing memory footprint)
- zerocopy data passing between the different ports
   (outputbuffer previous cycle == input buffer next cycle [& next
component])

>4) is there a fixed or variable method that a plugin should use
> when storing a value in a buffer?
>
When we would (and 'if'), use one buffer per input, then we could gain
extra efficiency, by using dynamically changing callbacks (run vs.
run_adding). Plugins hooked up to input ports, which are connected to
more than one output are set up with the run_adding callback, by our
good friend the LAAGA server. For one one one connections, the LAAGA
server passes the run callback to the plugin that has to produce the
audio (that does the output). This means that more costly methods (+=)
are only done where necessary (Mx1) and not in the 1x1 case. [remember
that for efficiency reasons, you have to rule out 1xN when using one
buffer per input, cause these setups would cause intermediary buffers,
forcing us to leave the "Zerocopy Principle"]

>the answers to these questions have profound and deep implications for
>the overall design and operation of a system.
>
Very true, that's why we have to have a good discussion over it.
{Note problematic discussions over email ... #lad on
irc.openprojects.com anyone ?}

>1) the engine/host owns (allocates, releases, assigns) all buffers.
>
Agreed (cfr. supra)

>2) buffers are associated with any port that allows multiple
> connections. most output ports would be multi-out, so
> typically, buffers would be associated with output
> ports. but multi-input ports would have their
> own input buffers too. when connecting up two
> such ports, it doesn't matter which one is chosen,
> as long as its done consistently.
>
I see, so you basicly try to optimize 'at runtime' ...
Hm, my guess is that we might be forced to choose one of both models
(see above).
If we want to achieve maximum eficiency (do we?)

>3) yes.
>
Hm, so you definitely want to go for MxN connections between ports.
If everyone is agreed to that, maybe I should stop whining ;-)

Is everyone agreed with this ??

>
>4) i'm not sure.
>
It certainly allows us to optimize even further.
Note: not optimize because we can (that's ridiculous), but because it
helps the plugins to remain stateless !!
They only have to call th callbackfunction, *without knowing* if it is
actually run or run_adding they are calling.

Kind Regards
Vincent


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon May 21 2001 - 02:45:33 EEST