Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Stefan Westerfeld (stefan_AT_space.twc.de)
Date: Wed Nov 22 2000 - 22:41:30 EET
Hi!
On Mon, Nov 20, 2000 at 05:14:05PM -0500, Paul Barton-Davis wrote:
> >> Without these characteristics, my "virtual studio" idea cannot be implemente
> >d.
> >>
> >> (You know: all "applications" runs as "plugins" of a main host, which
> >> never never never blocks (*) (mark the last 4 words .... ) )
> >
> >There might be some work to do on never blocking. For instance, currently
> >making a connection from inside artsd to the outside world involves seeing
> >if the outside world is still there (which means, blocking lookup).
> >Threading could be used solve this, or other (state-machine-driven)
> >approaches.
>
> well, here we come to the crux of things. if MCOP can really be used
> in applications that seek to offer the same kind of performance as
> dedicated h/w boxes, then i'm all for learning it and using it. [...]
>
> Stefan is probably right that MCOP could be improved/extended to
> handle such systems. But I suspect there is real work there, work that
> is not guaranteed to result in a version of MCOP that can still be
> considered universal in its utility. if stefan really believes that
> the fixes for this are fairly trivial superficial details, i'm very
> interested to know more. [...]
Okay, this could get really constructive here. We'll make a test. I will
give you three of the assumptions that I use, with an estimate how hard
it would be to undo (fix) them, then you can judge for yourself if it is
suitable for your purpose.
1. cross server object connection is done blocking
object1 object2
----------- -----------
Server S1 ..... mcop protocol ..... Server S2
Suppose you connect two server with the operation
connect(object1, "output", object2, "input");
Basically, it doesn't matter what data type we talk about (audio stream,
parameter stream). In any case, the connect operation itself blocks. This
is especially a problem if the servers are far apart, which might mean
that we will have quite a resulting latency (packet roundtrip delay at
least).
If MCOP was extended to support threads (no threads currently) by considering
each thread to a server, the same would apply for cross thread object
connection.
Fix: thread or state machine for cross server connects eliminates the
problem. This shouldn't be too hard to implement, though it may be a bit
of work. Such a change would really fit well into the mainstream MCOP.
2. audio data = floats
Audio data between different objects is passed as floats (except for cross
server transfers which can be done as arbitary formats). Every module
which produces or processes audio gets blocks of float data. The idea
behind it is that floats are easy to program with, reasonable fast on
modern computers and that float/int conversions are expensive. Thus, using
only floats is a better model than intermixing the two.
Fix: if you really wanted to have another format, such as 32bit integer or
16bit integer sampling data, you could extend the flow system of MCOP to
allow both. Maybe you could also add implicit conversions, maybe not. Such
a change could go into the mainstream MCOP, though mixing modules of both
types all the time would be unwise. But for the real first/last levels,
like recording audio data and playing audio data, it may make sense.
3. mallocs have reasonable costs
If you only run a fixed set of modules on one server, you don't need malloc.
All other operations, like connecting modules, sending events, calling
methods on other servers, connecting new servers,... do mallocs.
The assumption is that malloc has a reasonable cost, if you do these
operations, which due to their nature are somewhat expensive anyway (i.e.
sending a message to another server is never cheap).
Fix: removing this assumption generally for all cases will probably not be
possible. Maybe you can fix some special cases, like making establishing
connections on the same server malloc-free. Depending on how complex the
fix is, it could go into mainstream MCOP.
So this should give a good overview whether my assumptions fit to your
requirements or not. I am doing realtime synthesis with aRts all the time,
the kind of "play-on-keyboard-and-hear-result" kind of thing, which also
does dynamic connection and object creation during play. This works fine
on a standard kernel with 11ms delay, and probably you can't really test
below this with a standard kernel anyway.
I think there are no real realtime unfriendly pieces of code, but of course
it depends on how hard your requirements are and which kind of features you
will want to use while the requirements apply.
If you want to look at it, developer/API docs and standalone snapshots of
the sources are at
http://space.twc.de/~stefan/kde/arts-mcop-doc/
especially the book chapter is a good introduction.
Cu... Stefan
--
-* Stefan Westerfeld, stefan_AT_space.twc.de (PGP!), Hamburg/Germany
KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
This archive was generated by hypermail 2b28 : Wed Nov 22 2000 - 23:39:08 EET