Subject: Re: [ecasound] Adding/removing audio-objects on-the-fly?
From: janne halttunen (jhalttun@pp.htv.fi)
Date: Mon Jun 25 2001 - 13:19:00 EEST
> > 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.
--cut--
> 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... :(
Ok. I have a couple of ideas:
1. Assume unchanged audio parameters for changed objects. Removing an audio-object on-the-fly leaves an rtnull-object with all the memory reservations (+chain-operators, etc.)
in place, which can be used to add a new audio-object. (otf)
This would be analogous to dj's changing of disc on plate while the other disc/plate is playing.
2. Change ecasound architecture to support multiple engines running at once, mixing the outputs in a separate mixing engine.
This would entail the dreaded dynamic memory allocation, etc.. I really don't know if this is feasible/reasonable or not, just throwing ideas in the air.
> > 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.
It would be a great help. :)
> > 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...
..with no loss in performance or stability. ;)
janne
-- 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 - 14:32:33 EEST