[LAD] [Jack-Devel] jack2's dbus name

[Stéphane Letz]

>
> 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 at 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