see the very nice diagram of JACK done by joern on the JACK web site. it includes hints about using the ALSA sequencer for this purpose. not necessarily the best technical solution, but it works and it works right now. --p

On Sun, Nov 10, 2002 at 02:58:38 -0500, Ivica Bukvic wrote: I dont know Paul's particular reasons, but if an out-of-process client does some thing bad and hangs or segfaults then there will be a short (but anoying) click and it will get disconnected. If an in process client crashes the whole jack system stops. - Steve

"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. 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

no, thats completely possible. its been the design all along. as i mentioned previously, all that is missing is something like: jack_client_open_inprocess (...) its simple to write. i might even start it tonight. the existing ALSA "driver" for example, is nothing more than an I-P client that has also been assigned the role of "driver". completely. the main issue: kernel scheduling latency the side issue: kernel scheduling logic (probably fixed in 2.5/2.6) --p