On Tue, Nov 18, 2003 at 09:22:13AM -0500, Paul Davis wrote:
i suppose that if i knew this was possible 2 years
ago, i would never
have written JACK. that's the upside, perhaps. should JACK exist? is
the address space isolation worth it? big questions.
JACK should definitely exist, but it could be in a form that only
allows 'in-process' clients. This would put the inter-process
interface between the audio code and the GUI, were it is possibly a
lot less critical. I've always preferred this model, and in fact
use it in all my professional work. The hard work of creating a
lock-free (from the audio side) control and monitoring interface
is done by library code. If you use IP sockets between the two
parts (as we do here), you can even put the real-time code on a
dedicated compute server. As a nice side effect, such a model more
or less imposes an MCV architecture, which is also a good thing (TM).
For a large organisation as the one I work for, such an architecture
also permits separate development of the signal processing and the
GUI code. We always use a text format interface between the two parts,
so you can telnet to the DSP code and control it without the GUI.
The hard work with this approach is defining all the messages that
form the interface between the DSP code and the GUI. You really
need to do this before starting to work on the code itself. OTOH,
this means you start off with a very clear analysis of you
application.
--
FA