I use jack2 on a uniprocessor system. I either don't use a lot of jack
clients (compared to many LAU folk, probably true) or the ones I use are
all well-behaving JACK clients. Haven't had it get more than maybe 8%
CPU usage.
torbenh wrote:
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.
On Wed, Nov 17, 2010 at 02:50:02PM -0500, Paul Davis wrote:
[ ... ]
there are really 3 possible policies:
1) ignore all client behaviour (jack2)
2) try to zombify the misbehaving client(s) (jack1)
3) stop running the process() cycle if there is misbehaviour, and
restart whenever
the graph is rechained (indicating that a client has been removed, or
added, or connections where changed)
torben has been experimenting with an improved version of (2) and with (3)
my argumentation is that if i make the rules for (2) less agressive,
jack might not act up when you overload the cpu.
so i would basically like to protect the user by implementing (3)
after testing the overload situation i think the noise is not so bad.
and i would probably prefer this over silence, if i was on stage.
but UP people might want their cpu freed so they can fix the situation
quickly.
_______________________________________________
Jack-Devel mailing list
Jack-Devel@xxxxxxxxxxxxxxxxxxx
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
--
David
gnome@xxxxxxxxxxxxx
authenticity, honesty, community
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
