On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <[email protected]>wrote:
> > > 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 [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
