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.
But that information could be made available, couldn't it? I mean, the
Jack server has information about the graph, so it could make that
information available to the clients.
Hum...even if this info would be available, it does not say what
*actual* duration would take the following clients ...
what i am asking for is that events are either
passed into your RT
loop
via lock-free fifos
As mentioned, this is what happens. that lock-free q is called
pa_asyncmsgq.
Lennart
I think we should go back to the beginning of the discussion: allow PA
based audio desktop application be used in the JACK graph. It don't
think it make sense to over-complexify JACK or JACK/PA interaction
just to avoid a thread context switch.
Better keep the current separated simple solution, until it can be
proven it is a real bottleneck.
Stephane