Subject: Re: [linux-audio-user] Problem recording 24/7
From: Malcolm Baldridge (linux-audio_AT_paypc.com)
Date: Tue May 18 2004 - 12:52:53 EEST
> I'm trying to record 24/7 using Fedora Core 1, JACK 0.98,
> ecasound 2.3.3 , python2.2.3, alsa-1.0.1 and
> 2.4.22-1.2140.nptl.caps.rhfc1.ccrma kernel and delta 1010. I'm
> using the Planet CCRMA packages and kernel.
[...]
> After a couple of days of perfect recording,
> jack_connect just seems to hang while connecting and then all the
> subsequent instances of recording invoked from CRON pile and no
> more recording happens till JACK is restarted.
I have a (busy) file-server which runs 24/7/52 (P4-1.6Ghz/256MB PC133 RAM)
machine which records two channels of 16-bit/11KHz audio to disk when
there's sufficient loudness (VOX recording). I use a 2.4.25-lck1 kernel
(Con Kolivas's 2.4 rolled up preempt/HZ=1000/64-bit-jiffies patch, but
without patch-12).
My ALSA drivers are 1.0.3b and my ALSA libs are 1.0.4. My sound hardware is
Not Quality: onboard ECS P4IBMS with incorrectly designed i845 (Brookdale)
chipset hardware.
I'm using a late-April 2004 CVS of jackd and a custom vox-triggered
recording program which started life as one of the jack simple_client
programs, which I've turned into a small beast which always runs in a
detached TTY.
Both the jackd and voxrec run continuously, though when I'm updating voxrec
I stop/start it a great deal during debugging. I rarely restart jackd. The
last time was when I was experimenting with various mixer settings and
whatnot, and thought I might have some luck with ttable .asoundrc settings.
I've never had to stop/start jack because it went dead or unresponsive, even
after my abortive experiments with alsaplayer [strange and tricksy nasssty
little program that].
$ ps aux | grep jack
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
root 21283 0.0 4.6 12020 11972 pts/6 SL May13 2:09
COMMAND
/usr/local/bin/jackd -R -d alsa -S -C -p 4096 -M -n 2 -r 11025
$ ps aux | grep vox
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
root 21952 0.0 3.7 9636 9636 pts/6 SL May13 2:46
COMMAND
newvoxrec -v -a -0.0011 -f Line 1 -t 44100 -s 0.00315 -d 10800
alsa_pcm:capture_1 alsa_pcm:capture_2
This is showing that these processes have been running continuously over the
past 4.5-5 days. jackd's memory footprint slowly creeps up, but it seems to
hover around 11.5MB. After running it two weeks, it doesn't seem to use
that much more RAM, so I'm not too concerned. I should rewrite the voxrec
program though, as it's probably sloppier than it should be. But it works well.
> I can't figure out what could be causing the jack_connect
> instance to stall , whether it is JACK , jack_connect or ecasound
> or python I can't figure out.
You have many many layers I don't have in my setup. I don't believe in
strange OOP-like/"type-less" languages. Maybe python's chewing RAM. I
don't know ecasound. I believe in keeping things simple, when at all
possible. If you're open to skipping a few of those pudgy layers, I can let
you tryout my voxrec program which can be configured with command-line
switches to one-shot record something for you for exactly one hour.
> Any pointers or suggestions on how to solve the problem ?
Well, I can contribute my own voxrec program to the jackd group so they can
include with their samples - which would provide all kinds of nifty
functionality for people looking for 1) vox-activated recording with
configurable squelch level and hold times, 2) time-limited recording, 3)
time-stamping and sub-process spawning of sound washing/encoding scripts
complete with ID3v2 tag generation, 4) normalisation and optimal level
adjustment hinting to be provided to the washing script, etc.
In the shorter term, might I suggest the following:
1) You don't spawn/quit/spawn. Maybe opening up those connections to jackd
and just quitting the program is tying up descriptors or some other
non-infinite resource. Is the jack client properly shutting itself down,
closing channels, etc? Or it just hoping that the libraries are doing this
all properly when the program quits? UNIX programmers are notoriously lazy
and optimistic.
Try to keep your recording program running (and connected to jack) all the
time, and have it "turn on" and "turn off" at the appropriate times.
2) Fork your encoding process (better yet, fork to a SCRIPT so you can do
things like perform filtering, normalisation, and encoding however you see
fit). Remember to ignore SIGCHLD, otherwise your encoder subprocesses will
sit in ZOMBIE land forever when they're done. fork()/execve() are your friends.
3) If 1) is unappealing, then stop/restart jackd prior to invoking the
recording program. If this isn't practical because you use jackd for other
things, consider checking the return code of the recording program to
trigger a stop/restart of jackd.
Let me provide this Light of Quality, for the dark places when all other
lights go out,
=MB=
-- A focus on Quality.
This archive was generated by hypermail 2b28 : Tue May 18 2004 - 12:47:43 EEST