Subject: Re: [ecasound] Re: realtime effects with ecasound
From: Kai Vehmanen (k@eca.cx)
Date: Wed Mar 21 2001 - 23:19:31 EET
On Wed, 7 Mar 2001, Patrick Shirkey wrote:
> last time I tried using ecasound for realtime fx, every time I
> added/adjusted a new setting the sound would die for about 50ms then
> come back in with the new setting applied.
This is a known feature. I just added a short description of "Realtime
commands" to ecasound-iam(1) man page. Basicly, only a very limited set
of EIAM commands can be used to modify connected chainsetups. For
convenience, some common commands work semi-realtime (= processing
is automatically stopped with 'stop' -> cmd executed -> 'start').
'cop-add' is one of these semi-rt commands, so the delay is there on
purpose.
This all comes to the difficulties of realtime-app programming under
general use systems like Linux. Basicly all operation system services are
unreliable for audio engine's point of view. You can't allocate memory,
access disk drives, network stack, etc, etc .. All undeterministic
operation must be located in lower-priority threads, if we want to ensure
reliable operation. The new disk-buffering mode, -z:db, is a prime example
of these difficulties, and what app programmer has to solve.
Now when it comes to effects, it's very hard to avoid using OS
services. It's impossible to beforehand know what user is going to do, so
you have to dynamically create objects (=effects) at run time. Now this is
where it gets complicated: you must either implemented your own
rt-capable memory subsystem, or implement a system where objects are
first created in a lower-priority thread, and afterwards connected to the
engine.
So things get technically _very_ challenging. Nevertheless this is an
interesting issue, and my aim is to add rt-capability to more EIAM
commands. But this a delicate issue, so all possible design alternatives
must be carefully weighted. The worst case scenario here is that ecasound
engine will become complex and bloated --> rt-capabilities slow down
everything, even though no rt-features are used. This is very common
mistake made in many projects.
> This isn't quite realtime however I have used terminatorX and it can
> do real time so I'm not too worried about that wee problem
> dissapearing from ecasound over time.
Yup, the good thing is that I'm not fighting these problems alone. There's
been lots of talk about Linux rt-issues on linux-audio-dev.
> What I'm concerned with is the possiblity of having multiple fx
> processors(think boxes) running and being able to add them to or
> remove them from the sound stream without causing dropouts.
Aa, this is the difficult part. Ecasound's presets are basicly just what
you describe, small ecasound engines pretending to be effects. But tha
realtime add/remove part is more difficult. As ecasound presets can
contain pretty much anything (LADSPA plugins, multiple chains,
controllers, etc), you have a really complicated and dynamic environment
(==> bad for rt).
> This is where I see the true potential of live performance with
> computers. I don't think it can be done currently but, eyes to the
> stars eh?
Btw; have to taken look at PD; http://www.pure-data.org - I've heard
good things about it.
-- http://www.eca.cx Audio software for Linux!-- To unsubscribe send message 'unsubscribe' in the body of the message to <ecasound-list-request@wakkanet.fi>.
This archive was generated by hypermail 2b28 : Thu Mar 22 2001 - 00:00:34 EET