Subject: Re: [linux-audio-dev] questions to be resolved
From: Vincent Touquet (vincent_AT_ulyssis.org)
Date: Mon May 21 2001 - 12:23:48 EEST
Karl MacMillan wrote:
>[cut]
>Having the engine/host own the buffers seems more flexible to me and
>releives the plugin of some duties (particularly if those buffers are
>shared memory, etc).
>
Agreed.
>>2) are buffers associated with input ports, output ports, both or neither?
>>
>This could be an implementation detail assuming the plugin is not allowed
>to make certain assumptions (like the input and output buffers are
>different).
>
Not quite, it really makes a difference, if only because the plugin
reads from the input and writes the to output ...
Reading is not problematic, thus choosing a buffer per input allows you
just to read from that buffer.
The input-phase is uncomplicated.
The output phase is a little more problematic, because of the
possibility of M [out] x 1 [in] connections, thus requiring some sort
of += behaviour from the plugin.
Note that the plugin *doesn't* have to know if it uses = or += when you
use a callbackfunction, that can change dynamically according to the
connectivity of all plugins.
>>3) are multiple connections between ports allowed?
>>
>>Yes - this seems like a _very_ useful feature and one that users will
>>expect.
>>
I agree that this will be expected. But it is not possible to have
*zerocopy* buffers when you allow M [out] x N [in] connections.
How do you propose to handle this ?
I must admit that although this zerocopy buffer design issue is very
noble, we will just have to introduce intermediary buffers: also one
buffer per output, which are then mixed to the inputbuffer they are
connected to (either using = / += (!)), in the case we want to allow MxN
connections.
I think we will have to allow it, for the sake of usability.
Could we please try to agree on that ? Then we can proceed to tackle
further efficiency issues.
>>4) is there a fixed or variable method that a plugin should use
>> when storing a value in a buffer?
>>
>
>Fixed. I think the easiest model is for the plugin to only provide a run
>method. This is
> - easier for the plugin writer (having only one method that is)
> - potentially more efficient (mixing - run_adding - is only done when
> necessary
> - doesn't have to limit the system in any way
>
The plugin only has one run method, which can be implemented as a
callback function, that the host (be it a LAAGA server) can set during
runtime. I think that this is the point where LAAGA plugins or call them
soundboxes would be beginning to differ from LADSPA plugins (they don't
support dynamically changing callback functions ?).
The LAAGA server either sets the run method to a method which implements
a run or run_adding behaviour, according to the connectivity of the
plugins (soundboxes). This requires only a pointer change ! And it keeps
the plugin dumb, which is essential IMHO. The plugin doesn't even have
to know that there are two different output situations: 1x1 which will
use some implementation of run (=) or Mx1, which will use some
implementation of run_adding (+=).
Very important: note that the plugin in itself has no means what soever
to discover that it is in a Mx1 situation. So, it has to be told that it
has to use += in stead of =. To keep the plugin dumb, the only option I
see is a run callback function which is set by the LAAGA server.
Now the way I could see us arrive at a state where we could allow MxN
connections, without incurring too much extra buffers, would be to
introduce a special plugin (soundbox) for each output port which is
mapped to mutiple input port: a plugin which presents its input to N
outputs. Note that this incurs a delay of one period (cycle) into the
system, which I think is unacceptable ?
The only way out I see here is to tell the plugin that it will have to
output to multiple ports.
So the plugin automatically outputs to a list of ports (list of
pointers), which it holds (eg. with a maximum of MAX_OUTPUT_PORTS),
which can be changed at runtime by the LAAGA server
(add_output_port(pointer), remove_output_port(pointer)). This also makes
everything more flexible. I truly think that it won't be possible to
emulate such behaviour within the server in an efficient way.
>I would add one more question.
>
>5) Should LADSPA like plugins be supported? Mainly for operations like
> gain and panning between plugins.
>
I think LADSPA plugins may prove to be a little to simple to be able to
efficiently implement MxN connections.
Wrapping them into some LAAGA plugin wrapper would mean that you let the
LADSPA plugin output to an intermediary buffer, which is subsequently
sent to all registered output ports (as I see it). Which means an extra
intermediary buffer, one copie to be made, performance hit.
Note that while I'm talking about performance hits when using an extra
copy, I hav no actual data about this.
So the real cost might be not worth noticing.
I haven't got the time to test this though :(
Kind regards
Vincent
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 12:43:51 EEST