Subject: Re: [linux-audio-dev] MuCoS, Glame, API Issues
From: David Olofson (david_AT_gardena.net)
Date: ti maalis 07 2000 - 20:37:35 EST
On Tue, 07 Mar 2000, Alexander Ehlert wrote:
> 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.
Yes, this is exactly why we are working on a new API. We'd like to
come up with something that virtually *everyone* could use where
plugins are needed. This means that we need a very flexible solution
with minimum overhead and complexity. (Sounds like a nice and easy
job, right? ;-)
> 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
* Do you have to skip through linked lists or the like to find ports?
* When is a plugin allowed to add/remove a port?
* Can this be done in a separate thread without stalling the engine
thread until the whole operation has been performed?
> - filters can be combined to filternetworks, every filter runs as a new
> thread(we're using pthreads)
Although this allows a great deal of flexibility, it's definitely a
no-no for low latency audio in anything but RTOS environments like
QNX or RTLinux. There is too much overhead involved, there is a risk
of your engine being stalled by some kernel operation (even on
lowlatency kernels!), since each switch involves the kernel directly,
there are problems with scheduling multiple RT threads in low latency
settings (no preemptive/timesharing switching among SCHED_FIFO
threads), and some other things...
> - 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.
This sounds like quite some overhead to me... Also, there shouldn't
be any kernel calls (and preferably no function calls at all)
involved with the execution of a single plugin.
BTW, how do you keep track of time? (I mean, sample accurate
synchronization of plugins - plugin controlled buffering usually
implies that one doesn't have much control over delays between
plugins.)
> - automatic dynamic filter loading is not yet implemented but planned
Hmm... Triggered by what? :-)
Anyway, sorry for the harch reply - and for being incomprehensible,
if that's the case. That's just because we've been discussing all
forms of plugin API issues for some months around here, and
personally, I'm very interested in hard real time issues, as that is
the main reason I got into this in the first place. (Windows and Mac
systems are incapable of useful real time processing without
dedicated hardware...)
Your project seems very interesting, though. :-)
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:28 EST