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

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

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev