19 Jun
2009
19 Jun
'09
4:45 a.m.
No. I don't "wait" and not for the end of the current period. All I do
is set a maximum limit to how much non-IO work I do in the RT loop per
iteration.
Uh, I actually admit that the pseudocode I posted in
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/
023380.html
is completely broken. Sorry for the confusion. The one I was
describing down on
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/
023370.html
was correct.
So, another try:
<snip>
for (;;) {
n = jack_client_wait()
process(n);
jack_cycle_signal();
while (jack_frames_since_cycle_start() < threshold) {
if (no_private_events_to_process())
break;
process_one_of_my_private_events();
}
}
</snip>
The early exit in the inner loop when there's nothing to do (which is
the usual case) is the key point here, I guess.
Sorry for the confusion.
Lennart
--
Lennart Poettering Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/ GnuPG 0x1A015CC4
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
But why using a "timing" condition to know about "how much of this
event dispacthing" is going to be done?
Would it make sense to just process up to a specified number of
"waiting" events? So basically if events are waiting *now*, you
process some of them, and the one coming between now and the end of
the cycle would be processed next cycle.
<snip>, for (;;) {
n = jack_cycle_wait();
process(n);
jack_cycle_signal();
process_SOME_of_my_private_events(E);
}
</snip>
Stephane