On Fri, 24 Jan 2003, Paul Davis wrote: >>> period_size: 64 >>> buffer_size: 1728 > >So I guess this explains a lot. This equals to running jackd > >with "-p 64 -n 27" (and not as root or otherwise it will throw clients
Well, this is still true. >>well. And this has its reasons. With a setup like shown above, you either >>get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter > not that large. you don't multiply the period size by the buffer size > and the 1000 is extraneous too. the maximum latency is 1728/44100 = > 39ms, i think. i don't of any h/w that has a 2.5 second buffer!! Arrghghthghhg! :D 2500ms would have made a nice pro-jack argument, though.;) So the correct one is the 64*27/44100*1000=39ms you mention. > this is still pretty long, and as you note, pd is not subject to > per-period time limits with this configuration. it can take too long > on up to 26 of 27 periods before there is an xrun. Hmm, this is quite interesting. With a period size of 64 frames, you'd get quite a lot of context switches with jackd. Kjetil, does your ipc-lib make the context switches this often? Another interesting this is how this high interrupt frequency affects scheduling of (non-root) processes. I'd guess it could have a notable impact on reliability... have to try this later today with jackd. -- http://www.eca.cx Audio software for Linux!
