18 Nov
2010
18 Nov
'10
11:17 p.m.
Hi Torben,
2010/11/18 torbenh <torbenh(a)gmx.de>de>:
hi... i thought i take this to lau to get an impression on users
feelings.
here is the story. i basically wanted to improve the heuristics for
client zombification. i wanted jack to only kick clients which take a
whole cpu slice. the result would be that you can overload the cpu
with well behaving clients, and jack would not act on it.
the result in a synchronous jackd (jackd1/tschack or jackd2 -S)
would be continuous xruns, and probably bad noise.
the problem is that its not 100% possible to identify the bad client,
and its always possible, that we might kick an inocent client.
so many people on jack-dev advocate not kicking any client (this is what
jack2 does) jack2 users probably have an SMP system, so jack RT load at
100% doesnt mean their system is unresponsive.
for UP users it might make sense to stop processing after a continous
series of timeouts, so that the user can fix things up.
Being a long time jack user, mainly for recording purposes, I thought
I would speak up about my experiences.
I have always felt the unforgiving defaults of jack are very hard to
work with. When in the middle of a recording session, especially a
longer one, the last thing I want to happen is that jack kicks me.
It's quite alright to note the problem. Even if an xrun has occured it
can often be salvaged.
These days I always use -Z and -t to make jack cut me some slack.
Also, to be able to safely decide if an app has broken it's RT
promise, don't you also need to be sure the kernel has kept it's part?
Which in my experience has gotten better but isn't always true,
especially with some hardware configurations.
The one reason I see to let jack interfere is as you note, to avoid
lockups. Though if jack can detect this, leave it for a while (several
seconds) before doing anything about it.
Just my thoughts,
Robert