Subject: RE: [linux-audio-dev] MuCoS, Glame, API Issues
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: ti maalis 07 2000 - 07:39:47 EST
Hi there - nice API.
I've been trying to persuade the list to endorse a nice simple plugin API
standard that is compatible with *all* the current hosts out there at the
moment (e.g. MN, aRts, Quasimodo) with minimum hassle. This is an extremely
simple API that doesn't attempt anything in the least bit clever. The idea
is to go for the most complex API that will work with everything out there
with the minimum of wrapping. No threads, no sockets (the host is free to
use these if it wants), no events, even only one data type (float).
The current state of this is visible (messily, just to save posting it to
the list all the time) at http://www.muse.demon.co.uk/ladspa.html. How
would you feel about also supporting this API in Glame? - are there any
tweaks you could suggest that would make it simpler for Glame to use
without breaking it for other people?
An alternative would be to use a heavier-weight API, but there are so many
variations on this already (Quasimodo has one, MN has one, MuCoS uses
another, Glame has one etc) and the assumptions of each make it difficult
for other systems to wrap it. Rather than have everyone argue about how
their system does things best, the idea is to find the common ground so no
one's code has to be modified significantly.
-- Richard
-----Original Message-----
From: Alexander Ehlert [SMTP:ehlert_AT_phys.unsw.edu.au]
Sent: Tuesday, March 07, 2000 9:39 AM
To: linux-audio-dev_AT_ginette.musique.umontreal.ca
Cc: richard.guenther_AT_student.uni-tuebingen.de
Subject: [linux-audio-dev] MuCoS, Glame, API Issues
Hi all,
my second try to say hello to this list. I'm one of the developers of
glame(http://glame.sourceforge.net). I haven't been following all your
discussions here in detail, but from what I've seen, I think that our
so called "filter/filternetwork API" already addresses a lot of problems
that have been discussed in this mailing list.
I try to summarize the most important features and explain the terms we
use:
- a single effect is called filter(ok, I now it's bad...), a filter is
some kind of plugin that basically send/receives data through ports
- ports can be used for any kind of protocol, if you need a new one,
define one :), currently we've got a only a protocol for transfering
sample buffers. All protocols are just extensions of a basic buffer
protocol
- filters can be combined to filternetworks, every filter runs as a new
thread(we're using pthreads)
- pointers to buffer heads are sent via unix domain sockets. To
avoid memcpy's we do reference counting on buffers. filters can
make buffers private, if this is done by two filters a copy of the
buffer is made. Otherwise zero copy read-modify-write buffer
modification is possible on private buffers, that means processing
is done in place. After the buffer is processed it can be queued into
the next pipe.
- automatic dynamic filter loading is not yet implemented but planned
I think that's it for now, but richi will probably comment on this mail,
if something's missing
Cheers, Alex
------------------------------------------------------------------------
-------
When I am told, I forget
When I see, I remember,
When I do, I understand
(Confucius)
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST