On Fri, Jun 19, 2009 at 08:45:12AM +0200, Stéphane Letz wrote: > > > > > 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.
this discussion seems to go away from the real issue to implementation details of pa. however the deeper i read into stuff which is being called, the more malloc and mutex_lock() i see. even with jack_cycle_signal we are having a thread, which is running at the same priority as other jack threads, so it still has a certein potential to choke the other jack clients. first of all.... lets assume jack is running with -p64 -n2 (~3ms latency) i am not sure if lennart is aware that jack often runs with such latencies. i dont really care for event processing inside the RT loop. however you cant know how many clients are following in the process cycle, so you cant know a sane threshold value. what i am asking for is that events are either passed into your RT loop via lock-free fifos, or you decouple your soft-RT stuff from jacks RT stuff, which is not as soft as you think. at least nobody is creating semaphores in jack_process code. if you insist on soft-RT behaviour, just decouple and do what you want. > > > > Lennart > > > > -- > > Lennart Poettering Red Hat, Inc. > > lennart [at] poettering [dot] net > > http://0pointer.net/lennart/ GnuPG 0x1A015CC4 > > _______________________________________________ > > Linux-audio-dev mailing list > > [email protected] > > 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 > [email protected] > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
