24 May
2011
24 May
'11
12:56 a.m.
Hi folks,
I'm trying to build an audio logger, that can record from six different
sources to separate files. I've been using the program rotter, and I
thought it was working but have discovered that jackd crashed and recording
was interrupted. Unfortunately this was not reflected by qjackctl, which is
what I use to launch jackd. The qjackctl display showed that jackd was
running, right down to the flashing "RT", but when I tried to launch
meterbridge it complained that the jack server was not running. The
instances of rotter that I launched were still running, but were making
files of just a few bytes, with no audio in them. Is this a bug in
qjackctl? I am using Arch, on a Pentium 4, and using a firewire interface
(Edirol FA-101).
-Steiny
(415)819-2009
24 May
24 May
1:06 a.m.
On Mon, May 23, 2011 at 6:56 PM, Eric Steinberg
<eric.steinberg(a)gmail.com> wrote:
Hi folks,
I'm trying to build an audio logger, that can record from six different
sources to separate files. I've been using the program rotter, and I
thought it was working but have discovered that jackd crashed and recording
was interrupted. Unfortunately this was not reflected by qjackctl, which is
what I use to launch jackd. The qjackctl display showed that jackd was
running, right down to the flashing "RT", but when I tried to launch
meterbridge it complained that the jack server was not running. The
instances of rotter that I launched were still running, but were making
files of just a few bytes, with no audio in them. Is this a bug in
qjackctl? I am using Arch, on a Pentium 4, and using a firewire interface
(Edirol FA-101).
you should use:
ps aux | grep jackd
to establish whether jack has "crashed".
my guess is that had not crashed, but was no longer accepting new
clients and was otherwise hosed.
1:12 a.m.
Thanks, Paul. If jack had not crashed, shouldn't rotter have continued to
record? Is there any way to establish why recording was interrupted? This
happened about a week after I had started recording on this system.
On Mon, May 23, 2011 at 4:06 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Mon, May 23, 2011 at 6:56 PM, Eric Steinberg
<eric.steinberg(a)gmail.com> wrote:
Hi folks,
I'm trying to build an audio logger, that can record from six different
sources to separate files. I've been using the program rotter, and I
thought it was working but have discovered that jackd crashed and
recording
was interrupted. Unfortunately this was not
reflected by qjackctl, which
is
what I use to launch jackd. The qjackctl display
showed that jackd was
running, right down to the flashing "RT", but when I tried to launch
meterbridge it complained that the jack server was not running. The
instances of rotter that I launched were still running, but were making
files of just a few bytes, with no audio in them. Is this a bug in
qjackctl? I am using Arch, on a Pentium 4, and using a firewire
interface
(Edirol FA-101).
you should use:
ps aux | grep jackd
to establish whether jack has "crashed".
my guess is that had not crashed, but was no longer accepting new
clients and was otherwise hosed.
4:40 p.m.
On 05/24/2011 01:12 AM, Eric Steinberg wrote:
Thanks, Paul. If jack had not crashed, shouldn't
rotter have continued
to record? Is there any way to establish why recording was interrupted?
This happened about a week after I had started recording on this system.
interesting usecase. i never run jack for that long... but i guess some
people who are using it for museum exhibits do.
i think your best bet is to run jackd from the command line, using the
"screen" tool, so that it continues even if you log out or your X11
session dies.
i guess screen can be configured to have loads of line history, so that
you could retain lots of error messages. or you run
jackd 2> jack_stderr.log > jack_stdout.log &
then you have it all in files right away.
6:16 p.m.
On Tue, May 24, 2011 at 04:40:39PM +0200, Jörn Nettingsmeier wrote:
On 05/24/2011 01:12 AM, Eric Steinberg wrote:
It could be anything actually, but the first thing that went to my mind
was a 32bit integer overflow (sample count maybe) somewhere in the audio
software chain...
Thanks, Paul. If jack had not crashed,
shouldn't rotter have continued
to record? Is there any way to establish why recording was interrupted?
This happened about a week after I had started recording on this system.
interesting usecase. i never run jack for that long... but i guess
some people who are using it for museum exhibits do. 
25 May
25 May
10:29 p.m.
On Tue, May 24, 2011 at 06:16:49PM +0200, Roberto wrote:
On Tue, May 24, 2011 at 04:40:39PM +0200, Jörn
Nettingsmeier wrote:
I thought about that too, but then I started calculating:
4,294,967,296 (unsigned int of 32 bits) / 48000 (seconds)
/ 360 (hours) / 24 (days) = 1.035630617
So if it would be sample count, (jack_nframes_t),
it would overflow after approximately one day, I guess.
greetings,
lieven
On 05/24/2011 01:12 AM, Eric Steinberg wrote:
It could be anything actually, but the first thing that went to my mind
was a 32bit integer overflow (sample count maybe) somewhere in the audio
software chain... Thanks, Paul. If jack had not crashed,
shouldn't rotter have continued
to record? Is there any way to establish why recording was interrupted?
This happened about a week after I had started recording on this system.
interesting usecase. i never run jack for that long... but i guess
some people who are using it for museum exhibits do.
13 Jul
13 Jul
9 p.m.
Hey Paul and All,
I'm still having some problems with this. I'm using six instances of
Rotter, and patching them one per physical input with esjit. All seems to
go well for a while, usually; even though xruns stack up the recording still
happens. However, once in a while the files being written by Rotter get
mangled, resulting in there being a file of size 800k or so rather than the
circa 50 megabytes that is expected. I then have to kill the Rotter
instances, and jackd, and start over. I've tried this on Ubuntu Studio
11.04 and the latest Arch, with an Edirol FA-101, on a P4 3ghz with a second
sata drive as an audio volume. Most vexatious is that Rotter doesn't report
any issues even with the --verbose flag, and neither does jackd (other than
xruns of course). Roberto and Lieven mention integer overflow; is this
something that can be dealt with, or is it a hardware limitation?
On Mon, May 23, 2011 at 4:06 PM, Paul Davis <paul(a)linuxaudiosystems.com>wrote;wrote:
On Mon, May 23, 2011 at 6:56 PM, Eric Steinberg
<eric.steinberg(a)gmail.com> wrote:
Hi folks,
I'm trying to build an audio logger, that can record from six different
sources to separate files. I've been using the program rotter, and I
thought it was working but have discovered that jackd crashed and
recording
was interrupted. Unfortunately this was not
reflected by qjackctl, which
is
what I use to launch jackd. The qjackctl display
showed that jackd was
running, right down to the flashing "RT", but when I tried to launch
meterbridge it complained that the jack server was not running. The
instances of rotter that I launched were still running, but were making
files of just a few bytes, with no audio in them. Is this a bug in
qjackctl? I am using Arch, on a Pentium 4, and using a firewire
interface
(Edirol FA-101).
you should use:
ps aux | grep jackd
to establish whether jack has "crashed".
my guess is that had not crashed, but was no longer accepting new
clients and was otherwise hosed.
4911
days inactive
4962
days old
linux-audio-user@lists.linuxaudio.org
6 comments
5 participants
participants (5)
-
Eric Steinberg -
Jörn Nettingsmeier -
Lieven Moors -
Paul Davis -
Roberto