On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <mzynq@email-addr-hiddenwrote:
>
>
> This is a bit more complex than you might think. Jack's thread
> management is very unflexible and insists on controlling the entire
> thread life cycle, only calling into client code in very few
> occasions.
You might want to check out the more recent API additions:
jack_cycle_wait()
jack_cycle_signal()
which were created for precisely the sort of reasons you are describing.
>
> Of course it would great if JACK would be more flexible with its RT
> loop handling. What I am missing is basically a way to
> asynchronously/lock-free trigger execution of a callback function in
> the RT loop at a suitable place. By a "suitable place" I mean that the
> RT loop delays execution of this callback until a time where its
> impact would be minimal, i.e. right after a completed process() and a
> quick verification that the next process() cycle is still a bit away.
e.g. right after jack_cycle_signal()
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Fri Jun 19 00:15:02 2009
This archive was generated by hypermail 2.1.8 : Fri Jun 19 2009 - 00:15:02 EEST