Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Karl MacMillan (karlmac_AT_peabody.jhu.edu)
Date: Fri May 11 2001 - 02:45:30 EEST
On Thu, 10 May 2001, Paul Davis wrote:
>
> >Yes, but there is still an additional set of buffers for _every_ bus even
> >in cases where an intelligent server implementation could do away with
> >them.
>
> How ?
>
> Also, aren't you worried about the overhead of copying in out out
> >of the buses?
>
> If data is truly being *shared* (not sent from A to B) i don't see any
> other alternatives.
>
I guess I will answer these two together. First, it is not clear to me
what the difference is between 'sharing' buffers and 'sent from A to B'.
This is basically about allowing plugins access to the same data. Two
things make this easier - 1) only one plugin will run at a time and 2)
almost any signal flow graph can be simplified into a list (feedback loops
excepted). Note that to make this work the buffers have to be allocated
by the server. Here is an example:
A --> B
Here the server will allocate 1 buffer that A writes into and B reads
from. 1 buffer and no copies.
In the bus model you propose A would write from an internal buffer to a
bus and B would read from the bus to an internal buffer. That is 3
buffers and two copies.
Example 2:
A --> B -->D
\ ^
-> C ----|
In this example the output of A is split, goes into B and C, and then both
go into D. One solution to this is that the server will allocate two
buffers (1 and 2). Running the graph would be:
1. A writes to 1
2. B reads from 1 and writes to 2
3. C reads from 1 and writes to 1
4. 1 and 2 are added together into 1
5. D reads from 1
2 buffers and no copies.
In the bus model it seems like there would be 1 internal buffer for each
plugin, and 3 buses (A, B, C each write to a separate bus)? So that means
7 buffers plus 6 copies.
I could keep going here, but I will wait for your objections. I hope this
is clear.
> Finally, are there any drawbacks to my suggestion that you
> >see? Let me restate it concisely:
> >
> >1) Use LADSPA (potentially make run_adding the default a la RTCmix)
>
> as Jim noted, it would also have to modified to accomodate plugins
> whose input and output port count changes dynamically. this is
> not a small modification, since i think it requires a *server*
> callback to be provided to the plugin. i don't think this is
> a bad idea, but it would impact the "S" in LADSPA rather a lot!
>
This is true, though I am not certain whether it is a big change in
complexity.
> >2) Write a server that solves the signal flow graphs for efficiency
> > (PureData, Max/MSP, jMax).
>
> i've never read anything about any of these systems that would
> render them any more efficient than the system that aes is using
> now. signal flow graphs cannot solve feedback problems, and
> if A wants to *publish* data, I don't see how the buffer
> usage can be simplified. perhaps i don't understand enough
> about the optimizations that are possible. my notion of what a
> bus is for differs from the idea of "A talks to B".
>
Well, read what I wrote above. I think we are both missing something in
what the other is saying (I am not certain what you mean about buses and A
talks to B).
> >considering. Steinberg is a late comer to the realtime audio world when
> >you consider the work of some prominent computer musicians :)
>
> ... whose software products are used by how many people, and for what?
>
> i have great respect for the "pioneers", but their work (with MAX
> being a notable exception) is used by very few people and even then
> mostly for experimental non-real-time composition and editing.
>
This is a fair estimate - luckily most of my references have been to Max
like languages :) Seriously, I think that there are important lessons in
Max.
> we should look to history for lessons, but we should also look at
> contemporary successes as an indication of one outcome of those lessons.
>
Definitely. Steinberg is definitely a success and I think their APIs
represent one model of doing things. My goal is to present another valid
outcome.
> >> Yep, I like SKINI. But as I recall, it has typed messages, which
> >> LADSPA does not support.
> >>
> >
> >I think it does - I don't think this is a requirement for dealing with
> >this type of data, however. Dropping integers can make things a lot
> >simpler without a loss of functionality (look at PureData compared to
> >Max).
>
> Yes, but my point was that you'd have to find a way to deliver a
> message with the semantics of "CC #22, value 123" via a float control
> port. That doesn't seem very easy to do. Control data changes only
> once per cycle, and its single float value.
>
It is interesting that you say semantics - I would argue that for many of
the standard midi messages floating point represents the same meaning with
more precision. Obvious exceptions being channel and program numbers.
> >> input->pre_dsp_send->dsp_plugins->post_dsp_send->pan->gain->output
> >> | | | |
> >> out out out out
> >>
> >> that chain is executed for every route in Ardour, every time we are
> >> called from the engine.
> >>
> >
> >Paul, you are not understanding what I am saying. Here is some pseudo
> >code that might help:
> [ ... ]
> >At no point have I suggested inlining across plug-ins. In this example
>
> the diagram above is inside one single internal object inside one
> plugin to the server. it feels as if you are confusing LADSPA-level
> plugins doing simple DSP algorithms from a "LAAGA"-level application
> that does all of the above many times over. the chain above describes
> a single Route inside a single instance of Ardour, which is itself a
> plugin to AES.
>
Finally things make sense - yes I meant LADSPA plugins! Sorry I didn't
say that explicitly and didn't get that you hadn't read my mind. I was
simply trying to agree with you that handling run/run_adding automatically
is a good thing.
> your example code is nice and simple, and works well. but for a
> processing chain like the one above, i don't see how inlining could
> help very much.
>
This is absolutely true. Again, sorry I wasn't more clear!
Karl
> regards,
> --p
>
_____________________________________________________
| 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 : Fri May 11 2001 - 03:14:54 EEST