19 Jul
2011
19 Jul
'11
3:06 a.m.
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(a)gmail.com>wrote;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<Linux-audio-user@lists.linuxaudio.org>
http://lists.linuxaudio.org/**listinfo/linux-audio-user<http://lists.lin…