24 Jan
2003
24 Jan
'03
12:43 p.m.
On Fri, 24 Jan 2003, Paul Davis wrote:
Let me just say that I have just tested to see if k_jack could handle
lower latencies than 39msec running one freqtweak. And indeed it does. 9
msecs seems to work fine (no overruns), even when compiling QT3.1.1 in the
background. 4 msecs works too, but overruns happens when doing X things.
The machine this was tested on is an Asus a7n266-vm with xp2100 processor,
wd 8mb cache ide HD, 512 mb memory, inboard geforce2 gfx card and delta 44
soundcard.
kjetism@hensten ~ $ more /proc/version
Linux version 2.4.18-18.7.x (bhcompile(a)bugs.devel.redhat.com) (gcc version
2.96 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Wed Nov 13 20:29:30 EST
2002
On the other hand, 39msec does not work very fine on an other machine.
It is a 733mzh piii with asus cucl2 (or something) mainboard, 256 mb
memory, matrox g550 gfx card, samsung ide HD and delta 44 soundcard.
I _suspect_ its the GFX card (or driver) thats causing this.
kjetism@olivier ~ $ more /proc/version
Linux version 2.4.18-17.7.x (bhcompile(a)daffy.perf.redhat.com) (gcc version
2.96 20000731 (Red Hat Linux 7.3 2.96-112)) #1 Tue Oct 8 13:33:14 EDT 2002
kjetism@olivier ~ $
--
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.