[gmpi] Re: Separate Processes

  • From: David Olofson <david@xxxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Tue, 11 Feb 2003 18:18:53 +0100

On Tuesday 11 February 2003 16.10, Silver Blade wrote:
> I thought it'd be great if you could have the different plugin and
> audio/MIDI I/O technologies supported by some sort of universal
> host, which could be shared among processes - similar to how
> Windows sockets are implemented (ie, it manages sockets and
> provides apps with them.) This would mean you could share inputs
> and outputs between apps (no more complaints about a MIDI device
> being already open by another app!) and also that the only thing
> that would differ from program to program is the GUI layout,
> really.

I had this in mind for MAIA, but I doubt it will work in real life.

It's basically what JACK and ReWire do, although the latter doesn't=20
really run the "apps" in different processes, AFAIK.

The problem is that most general purpose operating systems are=20
incapable of doing this kind of communication while guaranteeing=20
usable and reliable latency. It can be done on Linux/lowlatency and=20
probably also BeOS and a few other media oriented operating systems,=20
but as it is, you can forget about it on Win32.

That said, as long as you never need to pass data with real time=20
constraints between apps and the "universal host", you're fine.=20
However, that reduces all apps to pure GUIs, and I suspect that many=20
developers just won't buy that concept.

Just for starters, it means major extra trouble if you want to do some=20
off-line processing. Should the universal host provide features for=20
that as well, or do you have to load and host the plugins yourself,=20
specifically for this job?

I think the JACK way is the only right way, but unfortunately, we=20
can't do it that way on the major platforms. It requires better=20
schedulers in the operating systems.

BTW, note that JACK doesn't allow applications to run asynchronously,=20
with different audio block sizes. This is not really a limitation of=20
JACK, but rather a *requirement* for low latency processing. The=20
read()/write() model just don't work for low latency DSP, and that's=20
not fixable in any way, not even with RTLinux, RTAI, QNX or some=20
other hard RTOS.

//David Olofson - Programmer, Composer, Open Source Advocate

=2E- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---

Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: