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

>
> 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@email-addr-hidden
> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 12:15:01 2009