Florian Schmidt wrote:
Here's the pseudo-code of the relevant MIDI player routine:
for (i = 0; i < number_of_events; i++) { usleep(event[i].delta_time_in_microseconds); output_and_drain_event(event[i]); }
This routine gives a non-bearable latency on 2.4 kernels but not so much on 2.6 kernels.
How could I get the app to <u|nano>sleep() in the most accurate way in userspace without using the ALSA queue nor the extra subscription to an output port? Or, is there a drain or output routine that supports callbacks? If so, I will be grateful if you could point them out. I seem not to find any output callback routine under the docs.
One way to improve timing is to make sure your process has the highest prio in the system, so that even in the case that other tasks want to run, too, at the moment of wakeup, your process gets the CPU.
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.
Also using a kernel patched with ingo molnar's -rt patches might help quite a bit (additional to running your process SCHED_FIFO).
Yes, I've been contemplating on doing that very soon.
Also you want to check on every wakeup (after your sleep expired) how long you really slept, so you can adjust the next sleep time. clock_gettime (CLOCK_MONOTONIC) might be useful for this..
This is new to me. I've never tried it but will try it ASAP.
Another approach, that works very well in my experience, is to not sleep the total required time until the next event, but rather regularly sleep for very short amounts of time (< 1ms), wakeup, measure the current time and if any event time now lies in the past, simply play it back immediately. This way the sleep time doesn't need to be accurate at all. All that's needed is that it's small enough to get some decent timing.
This seems reasonable enough. I'd try this out too.
Regards, Flo
Your ideas have been most helpful :)
Thank you very much!
Best Regards,
Carlo