[nama] Re: Bypass and ecasound crash.
- From: Joel Roth <joelz@xxxxxxxxx>
- To: nama@xxxxxxxxxxxxx
- Date: Fri, 6 Apr 2012 17:00:12 -1000
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.
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.
Until we get some logging, we are stuck with this
sort of trial-and-error testing, which is a PITA.
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.
For logging, it looks like Log::Log4perl does what
we want.
Regards,
> Cheers,
> S.M.
--
Joel Roth
Other related posts:
