Subject: [linux-audio-dev] LADMEA Prototype
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Thu Aug 09 2001 - 22:49:37 EEST
Hi folks, as some of you will know I've been looking into a more flexible
way to construct an inter-application data streaming approach, primarily for
audio but with support for general multimedia. At last (apologies for the
delay) I have a prototype API in the flavour of LADSPA. This can be seen at
http://www.ladspa.org/ladmea/. This prototype is somewhat rough and I'm
expecting a lot of modification.
This is a modified repost of a message that the LAD server bounced because
it was too long (thanks to Jörn for the prompt warning) as I included the
API rather than a web reference. The original mail was CC'd to pbd_AT_Op.Net,
wa_AT_almesberger.net, perex_AT_pf.jcu.cz and
gstreamer-devel_AT_lists.sourceforge.net.
In terms of compatibility (and as sources of ideas) I've been looking
particularly at LADSPA, Csound, MN, ATM, GStreamer, OSS, ALSA, LAAGA and
aRts. There is a deliberate separation and abstraction of both the 'client'
and 'exchange' sides of the API ('codecs' are supported too as specialised
clients). I should not be too hard to build exchange links using GStreamer,
LAAGA, ATM and aRts. It should be easy to write new clients or wrap existing
software such as Csound, Ardour, OSS and ALSA. A LADSPA client wrapper
should be trivial. The API (with suitable exchange design) should handle
real time and offline processing. All of this should be possible without
either the client or exchange knowing what they are connected to. Hopefully
it should be possible for the exchange to be in-process, in an external
process or on a remote machine and exchanges do not need to know what data
they are handling (although this can help).
Why should a good program with plugins (e.g. GStreamer) be interested in an
API like this? Hopefully the presence of a (relatively) simple API such as
this will allow two big steps forward: firstly, it should make it possible
for existing external applications such as GStreamer, Csound and Ardour to
work together. Secondly, it allows clients (or codecs) to be written once
and be used in/by many different applications in the same way that LADSPA
plugins are. The target license would allow commercial applications to use
the API too, but for the moment it will start under LGPL.
This API concerns itself with the interface between the exchange and client.
It does not assume a particular way in which the exchange will connect,
publish, merge or share channels. Synchronisation is kept simple and no
support for transport is provided (it is assumed that transport instructions
such as rewind be sent as data like any other). There are extensible calls
to request the streaming characteristics of channels and the latency
requirements of clients and data specifications are provided in an
extensible way that does not require any understanding on the part of the
exchange. Data types and descriptor conventions are given unique identifiers
to keep data types compatible.
I think the only point where the API strays from being strictly generic is
the insistence of use of a single timestamping scheme (managed by the
exchange) when sending data. I've had a lot of trouble persuading myself
that this is necessary but have come down in support of it. This doesn't
require the client or exchange to use this convention internally, just at
its interfaces, and it is hoped this won't be too hard to do.
On the web at http://www.ladspa.org/ladmea/ I've included the API itself
(ladmea.h) and two files containing the obligatory streaming characteristic
descriptor convention and latency requirement descriptor conventions that
all clients and exchanges should understand.
The name of the API is reasonably flexible - there's been lots of debate
about potential names for this sort of technology for LAAGA (which is
great). At this stage I'll observe that ALBA is already in use and JACK is
susceptible to unfortunate jokes.
I hope this is all of use - I've spent rather more time on it than I'd hoped
and I've cut off development to give me something to release. Which is
probably very broken in some way!
Please let me know what you think - like LADSPA, this API will only be any
use if people are prepared to use it.
--Richard
This archive was generated by hypermail 2b28 : Thu Aug 09 2001 - 22:51:31 EEST