[LAD] [Jack-Devel] jack2's dbus name

[Paul Davis]

On Thu, Jun 18, 2009 at 12:21 PM, Lennart Poettering <mzynq at 0pointer.de>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()
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20090618/695686b1/attachment.html>