Subject: Re: [Jackit-devel] Re: [ecasound] recording problems JACK,ecasound
From: H. T. Hind (hirh_AT_comcast.net)
Date: Mon May 24 2004 - 09:20:33 EEST
On Fri, May 21, 2004 at 06:55:37PM -0700, Fernando Pablo Lopez-Lezcano wrote:
> On Fri, 2004-05-21 at 17:50, H. T. Hind wrote:
> > On Fri, May 21, 2004 at 04:25:58PM -0400, Paul Davis wrote:
> > > >strace on jack shows -
> > > >futex(0x8064344, FUTEX_WAIT, 2, NULL
> > > >
> > > >as if it is waiting for a lock to be released.
> > > >
> > > >
> > > >I'm using JACK 0-98.1, ecasound 2.3.3, python 2.2.3 on a Planet
> > > >CCRMA kernel
> > >
> > > you must be running the barely-modified RH/CCRMA kernel. the standard
> > > 2.4 kernel doesn't use futexes. probably means nothing, but it just
> > > lept out at em.
> >
> > Yes, I'm running the RH/CCRMA kernel. I can try JACK under a
> > vanilla RH kernel and see if the problem persists. Would you
> > recommend that ? I started off using a vanilla kernel, but was
> > running into xruns and I read on the list that I would be better
> > off with a patched kernel like from CCRMA.
>
> Wait... which kernel are you booting? ("uname -r" to find out). There
> are two different kernels in Planet CCRMA land. If it is 2.4.26-1.ll
> then it is the latest "vanilla" Planet CCRMA (patched for best latency)
> kernel. If it is something else, then it is the "RedHat" kernel with
> capabilities, which has worse latency but better "compatibility" with
> the original unpatched RedHat kernel.
I'm running 2.4.22-1.2140.nptl.caps.rhfc1.ccrma on an FC1 system
and 2.4.20-28.1.caps.rh90.ccrmasmp on an RH9 sytem. Both the
system exhibit the same behaviour.
On the fc1 system, one ecasound instance output this message -
***********************************************************************
* Message from libecasoundc:
*
* 'ECASOUND' environment variable not set. Using the default value
* value 'ECASOUND=ecasound'.
***********************************************************************
(ecasoundc_sa) Error='read() error', cmd='' last_error='' cmd_cnt=1 last_cnt=0.
***********************************************************************
* Message from libecasoundc:
*
* A null client handle detected. This is usually caused by a bug
* in the ECI application. Please report this bug to the author of
* the program.
***********************************************************************
Warning: DBC_CHECK failed - "eci_rep != NULL", ecasoundc_sa.c, 675.
record
channels = ['3', '4', '5', '6'] time_to_process = 3600
and I lost that one hour of recording. All other recordings
worked. This system has now been recording 24 hours of 4 channels
for the past 8 days.
I'm going to check out the latest "vanilla" kernel on both
systems to see if the behaviour persists.
hth
--
This archive was generated by hypermail 2b28 : Mon May 24 2004 - 09:13:20 EEST