Subject: Re: [ecasound] Adding/removing audio-objects on-the-fly?
From: Kai Vehmanen (k@eca.cx)
Date: Mon Jun 25 2001 - 03:37:07 EEST
On Wed, 6 Jun 2001, janne halttunen wrote:
> Currently, when adding an audio-object, ecasound insists on
> disconnecting the chainsetup, so it can verify the validity of the
> setup, before connecting it again. This has the downside of forcing the
Actually is does quite a few things. When you connect a chainsetup,
ecasound starts the engine thread. Similarly, when you disconnect a
chainsetup, the engine thread is exited. So with the current ecasound,
changing the audio input/output configuration requires restarting the
whole engine. The same applies to all operations not included in
rt-commands list (see ecasound-iam(1)). And of couse, restarting the
engine takes time.
This is has popped up a few times on this list. See at least:
http://www.wakkanet.fi/~kaiv/ecasound/ecasound-list/2000/200003/0112.html
http://www.wakkanet.fi/~kaiv/ecasound/ecasound-list/2001/01/0007.html
http://www.wakkanet.fi/~kaiv/ecasound/ecasound-list/2001/02/0010.html
These are about adding/removing chainops, but same problems apply to
inputs and outputs (... or actually audio objects are even more
difficult).
But I'm still interested in this problem. Extending the on-the-fly feature
set is on my todo-list. But it'll take time. Implementing dynamic
behaviour (ability to alter configuration) in a
environment with realtime constraints (keeping up with the soundcard) is
technically very challenging.
A simple approach would be to add locking between the engine and the
user-inteface (console, gui, eci, etc). During each engine-loop we'd have
to...
- acquire the chainsetup lock
- check whether something has changed, and if has, updated
internal data structures
- do processing
- release lock
... now I'm afraid this design would work _very_ badly. First, just
acquiring the lock in each loop eats cpu-time. In the worst case, we try
to acquire the lock, but it's owned by the non-realtime thread
(user-interface). But as the engine is running with realtime-scheduling,
the user-space thread never gets to run (--> boom, you're machine is
completely dead).
Now there are solutions to the above problems. But we still have one major
problem, and that's updating the internal data structures. As it's now,
changing one chainsetup component can affect lots of data structures. For
instance replacing a 2ch input with a 24ch input, means that we need to
reserver lots more space for the input buffers, modify the attached chain
(+ all chain operators) to handle 24ch of audio. Performing these steps
requires so many undeterministic operations (like reserving memory) that
we have _very_ little chance of avoiding xruns...
So we need more clever techniques. And even if we achieve the wanted
behaviour, there will be a price. Dynamism doesn't come for free... :(
> user to have all the desired audio-objects in place before starting the
> operation. Also in the case of looping ewf-inputs this presents
> unnecessary burden to ecasound engine. Example:
True. On the other, comparing the extra load caused by unused audio
objects to the above "dynamic hell" scenario I described above, it's quite
low.
> - means audio-object is muted, but data is processed
> <space> means no audio data is processed
> drumloop1: *************--------------------------------------
> drumloop2: ---------***************---------------------------
> drumloop3: --------------------*****************---------------
> drumloop4: --------------------------------*********************
At the moment using ewf-files is the best solution performance-wise. When
having a large number of audio objects, disk i/o is usually the biggest
bottleneck.
> Now, I tried to wrap an ewf-file looping a wav-file to another ewf-file
> to get the behaviour above, but ecasound handled it like the second ewf
> was pointing to the wav-file. (it played only one time)
That's a bug in handling infinite source objects (like a looping 2nd
ewf-file). Similar behaviour can be triggered by specifying /dev/dsp as
source for an ewf file. I'll try to fix this.
> there would be also some other benefits in being able to add new
> audio-objects during operation. (living on the spur of the moment? ;)
Definitely. In the optimal case everything could be changed
on-the-fly...
> The validity of setup could perhaps be checked by adding the objects to
> existing 'null' or 'rtnull' -objects. (what's the difference of them
> anyway?)
Yup, using 'null' objects as placeholders is one idea I've been
considering. But there's still the problem of changed audio parameters
(more/less channels, etc). Plus it's rather impractical to use (how many
null objects would be enough etc).
Btw; 'rtnull' is like 'null' (just consumes audio or produces silence),
but it imitates normal soundcard behaviour. Just try the following:
'time ecasound -i somefile.wav -o null'
'time ecasound -i somefile.wav -o rtnull'
-- 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 : Mon Jun 25 2001 - 03:38:03 EEST