>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
