24 Jan
2003
24 Jan
'03
11:36 a.m.
On Fri, 24 Jan 2003, Paul Davis wrote:
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.
>> 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!! 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!