Re: [linux-audio-dev] Re: costs of IPC

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Re: costs of IPC
From: Jay Ts (jay_AT_toltec.metran.cx)
Date: Wed May 16 2001 - 23:58:29 EEST


> > > - performance (for SMP machine)
> > > - greater robustness
> > > - integration of audio applications not written as pure component
> >
> > Oops ... let me rephrase my question: Suppose I do not under *any*
> > circumstances (hypnosis, propaganda, torture, blackmail... :-) believe
> > the first two. Can you give us a specific example of an application,
> > maybe even a 'killer app', that *needs* the multi-process support,
> > and simply wouldn't be possible to implement otherwise?
>
> Are you asking if to be Turing equivalent it needs more than one
> process? ;-)))
>
> Seriously, I don't understand what you're asking.

Let me try again, and at the same time, maybe I've already thought
of a couple of examples.

Oh, why not ... I'll just throw out a general example. One possibility
that a multi-process approach would support is peer-to-peer audio applications.

Consider, there is COM on Windows and Corba on Unix to allow applications
to share and exchange data. (It works well with office apps, but not quite
audio! ;-)

And there is the traditional Unix text tool approach, where in the shell,
the output of a command can be piped to the input of another. Again, this
doesn't work well for audio apps!

Now, if we allow the plugin architecture to be more generalized and
work through IPC, then two audio applications (such as a software
synthesizer and an audio multitrack recorder) can work cooperatively,
streaming data and control signals between them. I haven't checked
into the spec, but I believe this would be analogous to mLan that
is being developed and implemented for hardware synths. (Which means
we should support it on Linux at some point, too!)

If we had this kind of support, then we will be able (in theory, but
maybe not on current hardware!) to link any two audio apps of any
type. This is the juicy possibility that excites me (in theory ;-).

To get just *slightly* more specific, consider if your favorite
multitrack recorder only does audio, and can't handle MIDI sequencing
(names of currently available apps left out very intentionally!).
It could be tied to a MIDI sequencer app, which could be tied to
a software synth:

        MIDI sequencer (incl. MIDI Input) -> Soft Synth -> Audio Recorder.

And we are now able to play a MIDI keyboard or MIDI file through
the Soft Synth and record it (in theory ;-). All in one computer,
in the digital domain. (Not terribly unlike a VST instrument in Cubase,
but the generalization of the architecture would allow for all sorts
of things to happen, not limited to the above example.)

The thing that really gets me about this is that we almost have all
this on Linux right now, if only we could plug them together in
a way that works. Whereas if we wait for someone to write a Cubase,
there may be no way for Open Source (or small companies) to create
that big, monolithic app, and that means we will have to sit around
waiting for Steinberg (or Emagic, or ...) to port their commercial
software to Linux. That might take a lot of evangelizing, which I
for one don't enjoy. I'd rather just go ahead and do it, using the
level playing field and networked cooperation of small development
groups (including individuals) that has worked so well for other
Linux software.

Now I need to say it again: We *need* to have a high-performance,
low-latency, single process architecture implemented, whereas what
I'm talking about here is necessarily of secondary importance.
And yet I feel that it is *very* important, to at least include
space in the design for this to be added. Absolute minimum! :)

Some have written that we don't need this right now, because we
can just rewrite it later. That may be easier said than done.
Consider what things are like when the architecture is implemented
and being used by a massive user base. Because if we are successful,
that will happen.

- Jay Ts
jayts_AT_bigfoot.com


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu May 17 2001 - 01:00:23 EEST