19 Jun
2009
19 Jun
'09
10:40 a.m.
On Fri, Jun 19, 2009 at 08:45:12AM +0200, Stéphane Letz wrote:
--
torben Hohn
http://galan.sourceforge.net -- The graphical Audio language
>
> 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(a)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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev