Subject: Re: [linux-audio-dev] questions to be resolved
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Mon May 21 2001 - 20:08:06 EEST
On Mon, 21 May 2001, Vincent Touquet wrote:
> 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.
>
Or the server can does this for you - you can do simple assignment (=) in
the plugin always and, as Paul said, have the Invisible Hand to mixing
when necessary. I think it is always better to have the complexity in the
server rather than the plugin.
> >>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.
>
With moderately smart graph sorting there will be zerocopy when it is
possible and not otherwise. This means that it can be an implementation
detail (i.e. hidden from the plugin) if the plugin is not allowed to
depend on the input and output buffers being different. Note that there
it is not necessary to have intermediate buffers, just make the input and
output buffers different for some plugins. This is slightly better than a
copy. I sent a message a while ago describing this in detail.
> >>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 (+=).
[snip]
I think Paul addressed this well.
> >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 :(
>
Again, there is no reason for the plugins to do anything but get data from
buffers and write data to buffers. The server can handle everything that
needs to happen to make MxN connections work.
Karl
> Kind regards
> Vincent
>
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| mambo.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Mon May 21 2001 - 20:27:55 EEST