Re: [ecasound] Bug report: strange crash

From: Joel Roth <joelz@email-addr-hidden>
Date: Tue Apr 10 2012 - 04:22:53 EEST

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)


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. :-)

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-

> - 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

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



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.
Ecasound-list mailing list
Received on Tue Apr 10 04:15:02 2012

This archive was generated by hypermail 2.1.8 : Tue Apr 10 2012 - 04:15:02 EEST