Interesting, but it's more like 48-72 hours, and sometimes as much as 100 hours before recordings start to break.  Others (Roberto, Lieven) on this list have mentioned integer overflow as a possible culprit, but I've been pretty consistent in the way I've set up recording, and the time-to-break is not consistent, i.e. it will sometimes go 4 or 5 days before breaking.  What is consistent is that there will be many xruns and then things will break.  I have not done hdparm on the disk used for recording, and I am not currently using an RT kernel (although I have used the Ubuntu Studio distro, with the same results as above).  

On Mon, Jul 18, 2011 at 5:49 PM, Gabriel Beddingfield <gabrbedd@gmail.com> wrote:
On 07/18/2011 06:02 PM, Eric Steinberg wrote:
jackd -v -d firewire -r 44100 -n 3 -p 4096 2> jack_stderr.log >
jack_stdout.log &

Snip...


This works, for a while.  Jackd still gets xruns, but the recording
happens and files are written properly.  However, after several hours
and a whole lot of xruns, it stops working.  Files are still written and
named properly, but they are only a few hundred k in size and contain no
audio.  The error logs show the xruns, but nothing else (no error

How many hours?  Is it a regular number?

What happens when jack_frame_time() overflows? (jack_nframes_t, 32-bit unsigned)  At 44.1k this would be about 27 hours.

-gabriel

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user