Subject: Re: my take on the "virtual studio" (monolith vs plugins) ... was Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Tue Nov 21 2000 - 03:12:59 EET
On Mon, 20 Nov 2000, you wrote:
>
> 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. but i also know that to date, every time i
> have looked at other linux audio software, i have found assumptions
> and world-models that make them unsuitable for use in live, real-time,
> low latency situations and/or situations working with hardware that is
> anything other than a consumer soundcard and/or situations that make
> it unsuitable for use with other pro-audio h/w.
>
(.....)
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.
Plus those that will want to use the "virtual studio" API out from a
C app will not like it that much.
(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.
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.
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 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)
BTW: does someone know what kind of audio routing capabilities
Cubase / Logic offer ? (I'm not very familiar with these apps)
Just to have some stuff for comparison.
Benno.
This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 02:19:18 EET