Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 21:24:54 EEST
>The complexity lies in the fact that all of the applications have to have
>user interface to do the connections - it is not necessary a matter of
>implementation complexity as it is conceptual complexity for users. The
>real point is about constraining server implementations. In your model
>only server
[... ??? ]
OK, point taken.
>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.
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!
>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".
>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.
we should look to history for lessons, but we should also look at
contemporary successes as an indication of one outcome of those lessons.
>> 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.
>> 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.
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.
regards,
--p
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 21:50:39 EEST