> >> 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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
