Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Thu May 10 2001 - 07:22:49 EEST
On Wed, 9 May 2001, Paul Davis wrote:
> >Perhaps I am missing something, but it is not clear in what order the
> >plugins will read and write to the channels. For example, to record a
>
> the LAAGA server will ensure this. its a simple sorting problem
> (unless there are feedback loops, in which case the problem is not
> solvable in a general sense).
>
Hmmm . . . . this doesn't really answer the question. There is no basis
for the sorting that I can see. Example: App1 requests to read and write
to channel 1 and App2 requests to read and write to channel 1. This is
not a feedback loop, but I can see no way to determine the order of the
reads and writes. Excuse me if I am missing something obvious, but what
is the simple sorting algorithm that can determine this?
> >It seems much easier to remove the whole concept of physical channels and
> >let the plugins simply request the number of channels that they want. The
>
> I don't understand this. The whole point of something like LAAGA is to
> present an abstraction actual physical channels and have that be
> unified with the way that data sharing is done. Channels correspond to
> resources: either physical i/o channels on an audio interface or some
> memory where data can be read/written.
>
The point of this is that there is no reason to present data to the
plugins that they cannot use - if there is no operational difference
between channels and buses the plugins shouldn't care. The result of
removing it is that servers are given more flexibility for their
implementation.
> >want - it could even use the entirely passive model. Of course, what is
> >left is basically LADSPA without the control ports. In fact, it strikes
> >me that LAAGA could be scraped and a LADSPA host could be written that
> >would handle everything that has been proposed here!
>
> LADSPA doesn't work unless you require that the plugins write to some
> intermediate buffer (they only have audio "ports" that they access as
> regular memory). This might be OK for a LADSPA plugin - for
> multichannel apps, you're forcing data copying on a large scale, which
> is rather pointless and very inefficient.
>
Well, this is the case with the run method but not the run_adding method.
I was forgetting that the default is run insead of run_adding. As far as
the buffering goes it is really just a simple directed graph sorting
problem - when there is no need for the extra buffering it could just go
away. When there is buffering you are left with a) more memory needed -
this is really not that large of a requirement and b) potentially more
L1/L2 cache misses - and I have not seen hard numbers that this would be a
big performance hit.
In summary, in the case of just the run method, running a single app like
Arduor would result in no extra buffering and running multiple apps might
result some buffering with unknown performance costs. In the case of
run_adding there is no extra buffering.
> I would note that this thought has crossed my mind too, but I think
> that LADSPA is clearly built around the idea of a plugin that "does
> one thing and does it well". LAAGA is designed entire applications,
> and I think that the simplifications made for LADSPA are not so
> appropriate here.
>
I would argue that these distinctions are present more in the discussion
and documentation than the apis. They are both about presenting a _very_
limited api for the exchange of audio data. The only real differences, in
my mind, are 1) the run thing and 2) control data. And as far as control
data goes, it seems like including that would allow the sharing of midi
like data between apps . . .
> However, my feelings on this are evolving. There might some good
> reasons to force the AES engine to use intermediate buffers, in which
> case {read_to,write_from}_channel would be redundant, and we could use
> the LADSPA audio port concept, and have the plugin just scribble on
> memory. OTOH, this brings up the run/run_adding dichotomy that I
> worked so hard to get away from ...
>
Well, I really like not having to care about the run/run_adding thing.
In my own software I write C++ classes that operate on single samples
(tick() in STK terms) and then make run and run_adding methods from that.
With function inlining everything is fast. I also use iterators to
abstract the buffer format, but I don't think that is going to make it
into any sort of api proposal for general use . . .
Anyway, I think it is worth thinking about just using LADSPA for this.
As Abramo says - one api is better than many :)
> --p
>
> ------
> To unsubscribe from <alsa-devel_AT_alsa-project.org> mailing list send message
> 'unsubscribe' in the body of message to <alsa-devel-request_AT_alsa-project.org>.
> BUG/SMALL PATCH REPORTING SYSTEM: http://www.alsa-project.org/cgi-bin/bugs
>
_____________________________________________________
| Karl W. MacMillan |
| Computer Music Department |
| Peabody Institute of the Johns Hopkins University |
| karlmac_AT_peabody.jhu.edu |
| www.peabody.jhu.edu/~karlmac |
-----------------------------------------------------
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 07:51:32 EEST