[nama] Re: Bypass and ecasound crash.
- From: "S. Massy" <lists@xxxxxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Sat, 7 Apr 2012 15:48:55 -0400
On Fri, Apr 06, 2012 at 05:00:12PM -1000, Joel Roth wrote:
> On Fri, Apr 06, 2012 at 06:41:09PM -0400, S. Massy wrote:
> > On Fri, Apr 06, 2012 at 06:33:49PM -0400, S. Massy wrote:
> > > On Fri, Apr 06, 2012 at 10:26:19AM -1000, Joel Roth wrote:
> > > > I've wrapped the code for replace_effect() with
> > > > jack_stop_do_start(), so both bypass and restore get
> > > > that, with a 0.03s delay for good luck.
> > > This is getting whhacky! Even though this is just a fancier way of doing
> > > what I was doing, ecasound still crashes with this method, even when
> > > increasing the delay to 0.1. This is puzzling...
> > But moving the sleeper before execution solves the problem... My guess
> > is we're facing some timing issue here.
>
> Good find. Perhaps we should allow for two delays,
> before and after. Let me know what delays work
> for you.
I had the same thought. I tried $delay/2 before and after, which mostly
worked, but would still sometimes crash; so I now have 2/3 of $delay
before and 1/3 after, which seems to be a winning combination so far. I
guess I could have tried just moving the sleeper before execution of
$coderef->(), but I feared it might cause problems with seeking. So far,
though, the 2/3 1/3 compromise seems to be a win/win. I also increased
fading resolution to 50 steps/second without immediately obvious
deleterious side-effects. Time will tell...
>
> Speaking generally, I've had timing issues in various
> places.
>
> Ecasound doesn't have any documentation about timing.
> One might assume that Ecasound would take ECI commands
> at the speed it can process them, but that assumption
> appears to be wrong :-(
>
> For Nama it becomes even more complicated because many
> "simple" commands include checks of the Ecasound engine
> status, playback position, etc. There is also various
> polling going on.
Yeah, I don't think anybody envisioned such a complex use-case at the
time the ECI was designed. The use-cases were mostly simple batch
processing or live DSP, I don't think anyone imagined a mad-scientist
would come and make a DAW out of ecasound! :)
>
> Until we get some logging, we are stuck with this
> sort of trial-and-error testing, which is a PITA.
The more these ecasound issues come up, the more I become convinced of
that. It gets difficult to determine which IAM commands interract to
cause crashes.
>
> I'd be interested to know if sending commands
> via socket is an atomic action. If not, perhaps we
> need to a create a queue or use a semaphore
> to avoid conflicts.
In the end, that probably would be the easiest solution: feed ecasound
piecemeal.
Cheers,
S.M.
Other related posts:
