Subject: [linux-audio-dev] MuCoS, Glame, API Issues
From: Alexander Ehlert (ehlert_AT_phys.unsw.edu.au)
Date: ti maalis 07 2000 - 04:39:10 EST
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