Dan Mills wrote:
> On 2 Apr 2006, at 17:42, Lee Revell wrote:
>> On Sun, 2006-04-02 at 17:21 +0100, Dan Mills wrote:
>>> On 1 Apr 2006, at 19:49, Lee Revell wrote:
>>>> On Sat, 2006-04-01 at 13:27 -0500, Eric Dantan Rzewnicki wrote:
>>>>> 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.
>>> There are caed bugs causing this! Please tell!
>> 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.
> 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!
it's not.
> 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.
patch -p1 < erics_braindead_patch
There is nothing to worry about. The question just came to mind because
I had managed to screw caed up enough to get it kicked out, so it
occured to me that we might want to consider softmode just for
insurance. Again, as far as I know the distributed caed does not have a
realtimeness problem.
mea culpa.
-ERic Rz.
Received on Mon Apr 3 20:15:04 2006
This archive was generated by hypermail 2.1.8 : Mon Apr 03 2006 - 20:15:04 EEST