On Fri, Sep 19, 2014 at 10:23:26PM +0100, Will Godfrey wrote: > Assuming buffer size and sample rate give 10.7 mS overall. > > Do the clients know when in the time frame they are actually called?
They can find out if they want (and some like the zita-*2* ones do in order to do their job the best way they can). But in general it doesn't matter. As long as all clients do their work before the start of the the next period it doesn't matter when exactly they run. If you want to find out, either call jack_frames_since_cycle_start() or call jack_get_time () and compare this to the data you get from jack_get_cycle_times() > Say we have A, B & C in that order and B&C each take 3mS to return but A takes > 6mS. Does C get booted out even though it was A that was the time hog? That will probably depend on the Jack version. IIRC Jack1 has some new ways to handle this. Paul Davis should be able to provide the details. In your example, what makes you thing that A is is the time hog ? It could be very legitimate for it to take more time. The real problem is that the sum is too large, who is to blame for that is not immediately clear. -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
