2 Apr
2006
2 Apr
'06
2:52 p.m.
On 2 Apr 2006, at 17:42, Lee Revell wrote:
On Sun, 2006-04-02 at 17:21 +0100, Dan Mills wrote:
The thing is, the RT thread is just not that CPU intensive, all the
heavy lifting
is done in the disk butler thread and the communication is via lock
free ring
buffers and volatile flags.
CAED should NOT be doing this!
Now it is possible for the disk (or network IO to under run in which
case the audio
breaks up, but that does not impact the process callaback.
Eric, can we have a way to reproduce please, this needs sorting.
Regards, Dan.
On 1 Apr 2006, at 19:49, Lee Revell wrote:
Yes - JACK will only kicks out clients that take too long in the
process() callback. Kernel induced xruns will not cause clients to be
disconnected.
If you build JACK with the preemption check option and use an -rt
kernel
with the debug options enabled you may be able to get a stack trace if
the app blocks in the process() callback, but it won't help to debug a
client that simply takes too long. On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan
Rzewnicki wrote:
There are caed bugs causing this! Please tell!
Thanks Paul. This is what I was hoping to hear.
At RFA they
probably
don't want Rivendell's caed (core audio engine daemon) getting
kicked
out by jack in the middle of a broadcast.
Soft mode is an OK workaround, but you should still try to get the
bug(s) in Rivendell fixed that are causing JACK to kick it out.