Re: [ecasound] Bug report: strange crash

On Mon, Apr 09, 2012 at 11:52:08PM +0300, Kai Vehmanen wrote:
> Hi,
>
> On Tue, 13 Mar 2012, S. Massy wrote:
>
> > A feature recently introduced in nama (single effect bypass) has brought
> > up some strange behaviour in ecasound. When the effect being bypassed is
> > removed, or around that event, ecasound segfaults. Here is the
>
> I think I've figured out what's going wrong:
>
> - cop-remove (and cop-add), which are used to implement
> single effect bypass in Nama, are not real-time safe calls;
> see full list in ecasound-iam(1)

Kai,

Thanks for helping to track this down!
 
I note that ecasound-iam(1) for my version of Ecasound (2.8.1)
does not list cop-add and cop-remove as non-realtime (see
quoted text below).

Perhaps there are others as well? For example, I know
that Nama needs to wrap cs-set-position in a stop/start
when running Ecasound under JACK.

Also, as I read it, this section should be called
*Non-realtime* commands. :-)

--quote-2.8.1---------------------------------------------
Real-time commands
       It's not possible to use all interactive mode commands to modify and con-
       trol objects that belong to a connected chainsetup. Commands that do NOT
       support this are:

              cs-remove, cs-set-length, cs-set-length-samples, cs-toggle-loop,
              cs-set-param, cs-option, c-add, c-remove, c-rename, c-clear, ai-
              add, ai-remove, ai-attach, ai-forward, ai-rewind, ai-set-posi-
              tion, ai-set-position-samples, ao-add, ao-add-default, ao-remove,
              ao-attach, ao-forward, ao-rewind, ao-set-position, ao-set-posi-
              tion-samples.
--end-quote------------------------------------------------

> - when they are issues while engine is running, ecasound
> implements an automatic stop-reconfigure-restart process

> ... now the bad news is that this logic starts to fail when fed a lot of
> commands (from an app, versus a live person typing commands in interactive
> mode).

Not especially bad news, as I can work around these
limitations, now that they've been brought to my attention.
(I admit it's been quite a while since I comprehensively
reviewed the Ecasound docs. :-)

> Easiest way to reproduce is to take your example chainsetup, start
> it, and then copy'n'paste the following into ecasound's shell:
 
> c-select 9
> cop-add -ea:100
> cop-remove

(snip nasty test case resulting in epic failure)

> This needs to be fixed of course, but a not a trivial task I'm afraid. One
> practical workaround is to explicitly stop and start the engine from the
> app, before doing non-realtime-safe edits like cop-add/cop-remove. For
> Nama specifically, adding real-time safe "cop-bypass" would be a nice
> alternative as well.

Well, no hurry on either of these issues. In coding for
Nama, I sometimes have a problem knowing how long to allow
for these slow-to-execute commands.

I suppose it's a complicated relationship to number of
chains, number of files open and number of chain operators.
Generally I've just used trial-and-error to find a safe
margin.

I look forward to making Nama more reliable for its users.

Regards

Joel

-- 
Joel Roth
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list