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

[torbenh at gmx.de]

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 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
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

-- 
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language