Re: 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ecasound-list