On Wednesday 25 July 2007, Carlo Florendo wrote:
Try running your process with SCHED_FIFO scheduling and a high prio of e.g. 99.
I've tried that in kernel 2.4 and I get the same latency results. Let me try tweaking that though by running the system with high priority. The reason why I'd like to make it work in 2.4 kernels is so that existing systems with 2.4 kernels could run the app without need for a kernel patch.
2.4.x kernels are terribly unsuited to do any serious sort of realtime work, be it audio or midi.
From my experience this is a classification with increasing suitedness for realtime work:
1] vanilla 2.4.x 2] patched 2.4.x [lowlatency patches] 3] vanilla 2.6.x 4] patched 2.6.x [ingo molnar's realtime preemption patches]
There really should be like 100 bogus places between 2] and 3] and another 100 between unpatched and patched 2.6.x because 2.6.x really is vastly better than 2.4.x and -rt patched 2.6.x actually is a realtime system which can be made to work up to microsecond resolution [not millisecond ;)].
Your ideas have been most helpful :)
No problem. BTW: even when you use ALSA queues, the kernel still plays a big role. Then it's simply ALSA's responsibility to provide good timing and it basically uses the same mechanisms as a userspace program would.
So thrash 2.4.x for all realtime purposes..
Flo