> 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.
