[linux-audio-dev] XAP and JACK

[David Olofson]

On Monday 16 December 2002 14.30, Frank van de Pol wrote:
> On Mon, Dec 16, 2002 at 08:09:18AM -0500, Paul Davis wrote:
> > also, to repeat the perennial advertisement, if your application
> > has no reason to attach itself to a particular audio interface
> > and might benefit from being able to route data to/from other
> > applications, consider using JACK (http://jackit.sf.net/).
>
> Which reminds me of some earlier thoughs: The whole discussion on
> XAP is about the in process plugin model if I'm correct. Why not
> include an out of process model like JACK? I suppose a union
> between JACK/LASDPA/XAP would be a good thing for the linux audio
> community.

I don't think a direct union would result in a clean API, and I don't 
really see a strong motivation enough, to make up for the technical 
issue and API complexity that it would imply.

	* JACK is for the *really* big "plugins", that may have
	  their own threads for background work, direct use of
	  various GUI toolkits and whatnot. In short, entire
	  applications.

	* XAP is for anything from simple effects through big,
	  monolith synths and samplers. A XAP plugin could be
	  seen as an application, but the plugin itself; the
	  actual DSP part that runs inside another application,
	  lives in a world with many restrictions. For example,
	  forget about using your favourite toolkit to implement
	  a GUI in another thread.

	* LADSPA is meant to be simple. Easy to use, for both
	  host and plugin developers. If we make a *really*
	  good job with XAP and it's plugin and host SDKs, XAP
	  might eventually render LADSPA obsolete. My standard
	  comment: "You don't know anything about the future." ;-)


So, XAP is supposed to be a superset of LADSPA, and could possibly 
replace it eventually. Joining the two is not an option, because it 
would only result in some features being doubled.

As to JACK, there are too many technical complications to just throw 
the two models into the same API.

Why use external processes and shared memory for custom XAP GUIs (or 
use whatever custom toolkit we decide should go into the host SDK, if 
that ever happens), when you can use JACK and whatever toolkit you 
like in another thread?

Why have *both* the host oriented API of JACK, and the "stupid black 
box of DSP code" philosophy of XAP in the same API, when you can 
really use only one at a time? (Either you're in control of the net, 
or you're not.)



>
> Of course things like callbacks are not quite handy for out of
> process plugins (unless using RPC stuff).

That would be async RPC, since you're never allowed to block the 
host, unless you're a driver.


> I personally like the
> concept of being able to run various components in it's own
> process, it's own protected VM etc. just for the sake of robustness
> and ease of debugging.

Yes, that's why you should use JACK. If you do that kind of stuff, 
your plugin simply cannot run as an .so plugin inside a host - part 
because of the different world view, part because of conflicting 
libraries; most importantly GUI toolkits.

If you just want to *develop* a legal XAP plugin in it's own process, 
just use a very simple XAP host, that connects to JACK as a client.

If you want a custom GUI for your XAP plugin, well, then I'll have to 
think for a few more minutes to give you a detailed answer. ;-) 

Seriously, I think XAP hosts should be able to export Controls from 
XAP plugins in a "soft RT" manner, to be used exactly for this 
purpose. The GUIs would be registered in similar ways to plugins, and 
should understand some standardized arguments, so hosts can find 
them, start them up and connect them to the right instance when 
desired. Obiously, the interaction would be based on the usual XAP 
Events on the plugin side (no news there), while GUIs would use a 
similar API. To make smooth animation and control possible, I think 
GUIs should have access to timestamps and the host's current time, 
but obviously, the host's event gateway would have to adjust events 
that arrive late from GUIs.


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

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