linuxaudio.org

On Fri, Jun 19, 2009 at 08:45:12AM +0200, Stéphane Letz wrote:

quoted text
>

> >

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

> >

> >

> > 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();

> >     }

> > }

> >

> >

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

quoted text
> > 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@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.

>

> , for (;;) {

> 	n = jack_cycle_wait();

>          process(n);

>          jack_cycle_signal();

>          process_SOME_of_my_private_events(E);

>   }

>

>

>

> Stephane

> _______________________________________________

> Linux-audio-dev mailing list

> Linux-audio-dev@lists.linuxaudio.org

> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev