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.
i have been unable to reliably run jackd with a period size of 64
frames on my dual CPU system. you may recall that i spent considerable
time trying to track down what was preventing it from happening, to no
avail. something in the kernel appears to prevent reliable scheduling
at this level. that is, jackd is not reliably woken by the kernel when
the audio interface interrupt arrives, or rather, its not reliably
woken in time to properly service the interrupt. and if not that, then
the kernel fails to reliably and promptly schedule the other
clients. with only 2 periods per buffer, these scheduling errors are
fatal. it will be interesting to see how 2.5 performs in this regard.
pd (with the configuration kjetil has shown) would be unaffected by
this unless it affected 27 periods in a row, which is rather
unlikely.
note, however, that jack can be used with this same configuration. i
just don't know anyone who would want the results: high interrupt
load, and unacceptably large latency for live performance - the worst
of both worlds :)
--p