Subject: Re: [linux-audio-dev] Looking for some PR stuff related to Jack
From: Paul Davis (paul_AT_linuxaudiosystems.com)
Date: Mon Nov 11 2002 - 04:29:51 EET
>> Pardon my ignorance, as well as probably beating a dead horse, but I
>> would appreciate just a quick insight as to why is out-of-process client
>> better than in-process, or if not, why is ardour geared towards being
>> out-of-process app, when (at least judging from the info I've gotten so
>> far) in-process stuff provides so much better performance?
"so much" is a relative term. the problem with terms like this is that
it suggests that you can get JACK+O-o-P to work at 2.6msec at
all. this is not true. the difference is that its not as reliable as
JACK+I-P.
in addition, i strongly suspect that the effect is partly related to
the cache effects of a given client. if you were running JACK with
relatively simple clients like FreqTweak, it wouldn't suprise me if
you could get exactly the same performance from the O-O-P and I-P cases.
>> I am completely clueless on this seemingly low-level issue so any quick
>> insight would be greatly appreciated!
>
>There were several reasons, but the main issue was the inablility of
>current Linux GUI toolkits to share an address space. Giving each
>application in its own process allows it to use any user interface
>tools it wants, independent of other applications' choices.
totally correct. but there's more.
the in-process model means that the GUI for your plugin/client doesn't
run in the same process as the plugin itself. all communication
between them needs to occur via some kind of IPC (a pipe is
recommended), and requires an extra thread in the plugin to handle the
I/O. its no longer possible for the GUI to consider itself to have
direct access to objects in the "Model" (the "engine" or
"backend"). instead, all operations it performs have to be done
indirectly via IPC.
now, i will admit that there is a great benefit to writing a program
with this expectation in mind right from the start. Pd works this way,
as does jMax. it encourages the use of a nice formal mechanism for the
View/Controller parts of a program to interact with the Model.
however, it also massively complicates certain things. for example,
its no longer possible to use a beautiful callback library for
anonymous notification of changes in Model state without a hack in
that library to make it work over an IPC mechanism. in addition,
converting a program that was written with the idea of direct
Model<->View/Controller access as a basic assumption is a lot of
work.
ardour has all kinds of code like this in the GUI:
/* change someObject to reflect what the user just requested */
someObject.someMethod (arg1, arg2);
if someObject is actually part of the *plugin* and not the GUI, then
"someMethod" needs to be a proxy call that sends a request over
IPC. all of a sudden, things get pretty hairy.
now, to be honest, for a relatively simple plugin/client, like a drum
machine, this isn't much a problem. the machine has a relatively
simple "state"; the GUI modifies the state from time to time; the
engine runs continuously using the current state. not too much of a
problem.
but big, complicated models are not anywhere near as easy. consider
the simple act of dragging a region (a chunk of audio) in
ardour. here's what is going on during this process:
ask the relevant playlist to save its current state;
while (mouse_dragging) {
if (the new position is a legal place for the region to be)
redraw the display to show a new position;
}
if (the receiving playlist is not the same as the source playlist)
tell the receiving playlist to save its current state;
edit one or two playlists;
store the operations in the undo/redo system
(this is sometwhat simplified)
this process involves lots of interaction with the "Model", even from
the mouse motion event handler. its almost unimaginable to me that
you could do this with a "smooth" feeling if every check on the
Model's state involves some kind of IPC.
so now you have to come up with complex schemes to cache part of the
Model state in the GUI process ...
as you can hopefully see, things start to get more and more and more
complex. its not impossible to do this, but its hard, and i have much
more important things on my mind than re-engineering the 80,000 lines
of Ardour's code to make an in-process version possible.
--p
This archive was generated by hypermail 2b28 : Mon Nov 11 2002 - 04:31:46 EET