On Fri, Sep 19, 2014 at 11:16:38PM -0700, Len Ovens wrote: > On Fri, 19 Sep 2014, Will Godfrey wrote: > > >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? > > The expectation is that there is enough time to finish a,b and c > all the time.
Which is also why clients should be designed to take the same time in each period. This time may depend on what the client is doing, e.g. on the number of active voices in a synth, but in all cases the work should be spread equally over all periods. In most cases that will not require anything special, the exception being clients that use block algorithms like an FFT. The worst offenders here are apps that were not designed as Jack apps in the first place, and use a large internal period size with some buffering in between. They will e.g. do nothing for a number of periods, then bunch all the work for those in a single one. Such apps should really run their DSP code in a lower priority thread. This will mean more latency, but at least that makes them usable. Ciao, -- 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 Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev