[Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15

[Kai Vehmanen]

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!