<br><br><div class="gmail_quote">On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <span dir="ltr"><<a href="mailto:mzynq@0pointer.de">mzynq@0pointer.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
This is a bit more complex than you might think. Jack's thread<br>
management is very unflexible and insists on controlling the entire<br>
thread life cycle, only calling into client code in very few<br>
occasions. </blockquote><div><br>You might want to check out the more recent API additions:<br><br>jack_cycle_wait()<br>jack_cycle_signal()<br><br>which were created for precisely the sort of reasons you are describing.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Of course it would great if JACK would be more flexible with its RT<br>
loop handling. What I am missing is basically a way to<br>
asynchronously/lock-free trigger execution of a callback function in<br>
the RT loop at a suitable place. By a "suitable place" I mean that the<br>
RT loop delays execution of this callback until a time where its<br>
impact would be minimal, i.e. right after a completed process() and a<br>
quick verification that the next process() cycle is still a bit away.</blockquote><div><br>e.g. right after jack_cycle_signal() <br><br></div></div><br>