[linux-audio-dev] Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Sladen (paul_AT_sladen.org)
Date: Tue Nov 21 2000 - 02:53:19 EET


On Tue, 21 Nov 2000, Benno Senoner wrote:

> Yesterday I had a chat with David Olofson about these issues:
>
> we came to the conclusion that although some object oriented model
> will be required, we need to keep it as simple as possible
> (keep it simple stupid).
>
> And for this C++ may not the right way to go.
> As we all know C++ is a difficult beast to handle and you need to
> know what you do when talking with abstract objects AND want
> RT-safe behaviour.

Anything that /depends/ upon a persific language is fundementally flawed..
if you have an API that ports easily across all languages, then you know
that you have come up with a good answer... Why /shouldn't/ I be able to
knock up a quick plug in Python etc...

<abstract rant>
OpenGL is an example of a language that has successfully be bound to
many, many lanuages... and while not all of us (ie, me) may not have had
the benifit of 10years experience in the field, and various previous
attempts, SGI did have when they designed OpenGL.

It has taken Microsoft *8* versions of Direct3D to do all the things that
could be done with OpenGL 1.0!!!!
</abstract rant>

> Plus those that will want to use the "virtual studio" API out from a
> C app will not like it that much.
Indeed, "they" will not like it very much at all ;-).

> (ever tried to write a Qt application in C ? no way .. (almost) ).
>
> Plus this delegating the establishement/destroying of connections to
> a separate thread is not going to solve our problems.
But what it does do is not disrupt the RT process when it /needs/ to be
running. The server needs to be running nonRT, and the plugin chain, and
only the plugin chain, RT.

> There may be cases where we want to make/modify connections in realtime
> without glitches and other sources of non-determinism and here we need
> to be VERY careful.
What needs to happen is that the nonRT needs to do all the calculation,
and then place all the changes into a lock free FIFO for the RT chain to
pick up after/before processing the next block.

After is better for realtime-online schemes, where latency is the worry,
whereas before is better for offline processing using big blocksizes. P

> David and I discussed the SMP issues too: how to spread the load among CPUs,
> reduce the interdependencies and try to keep latency as low as possible.
> We haven't solved the problem fully, but what's for sure is that we need to
> make certain tradeoffs about what kinds of plugin trees can be processed.

The only option that I've come up with is passing a "timeframe" parameter
around too.... example:

+======================+
| P1 |
+====v============v====+
     V V
+====V====+ +====V====+
| P2 | | P3 |
+====v====+ +====v====+
     V V
+====V============V====+
| P4 |
+====v============v====+
     V V

P4 (in my system) makes requests to P3, and P2, who in turn make a request
to P1.

(if P1 is capable, an optimisation to this could be done, knowing that P1
will have been called by P2, it knows that it doesn't have to tell P3 to
call P1 /aswell/... but this is an optimisation).

-*- But!

Say that P2 is a reverb or band-pass filter, and caches the last "n"
samples of input.... and the two chains get call "out-of-order"...

Ok, so we create two descrete /chains/ or instances?... But what happens
about the second instance of P2 picking up the first instance of P2's
cached input... this needs a timeframe to allow for this type of things,
and one thing that it can do is to block until the previous interation has
finished processing.

ie it has to wait until it has processed all it's input,and then can
proceed and unblock onthe second channel.

Problem in the sentance; the word "block"... don't like this.

> The main issue is the interdependency problem:
> if one CPU has to wait for the results of the other then you must either halt
> execution on that one, or use some kind of pipelining which increases latency.
> And with a few of such interdependency places, low-latency vanishes.
>
> The tradeoff would be to process individual independent chains which can be
> spread among the available CPUs (or nodes in a cluster).
> And to allow only a small number of interdependency places.
> (that would be the final dowmix/routing of all tracks or some common
> FX processing)

I guess what the plugin needs is a flag stateing whether it relies on
previously passed data, or whether it is **completely** dependant on it's
input and it's input /only/. GCC has a __keyword__ for this, so there is
a word that means it. (GCC has nothing to do with the problem at hand
before I get anyone confused!).

Paul

--
e: paul_AT_sladen.org   t: 0115 922 7162


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 03:37:18 EET