Paul Davis wrote: >none of this, alas, addresses the more fundamental question of how to >do the timing correctly. without something like the hard-timer patch, >its more or less impossible to do MIDI sequencing correctly under >linux. of course, you can do it "well enough" with existing >mechanisms, but the reason most people haven't noticed this yet is >that there is fairly strong division between audio + MIDI >software. its only when *this* MIDI event needs to be delivered at >audio frame N that you start to see the problems. there is no way to >accurately schedule anything under Linux with hard-timers unless by >accurately you mean either "resolution = HZ" or "resolution = RTC Hz" >or "resolution = audio interrupt frequency".
I find that for sending MIDI to an external device, "resolution = RTC Hz" works very well. It is a problem that a realtime audio thread 'suffocates' a RTC thread if low-latency is required, and only one processor available. It's very hard to find a clean solution in this case, but firm timers obviously do not address this particular problem. Since Jack is an Audio Connection Kit (and intended at large to stay audio iirc), all we need is to prequeue events for the next audio cycle, and get "resolution = audio sample rate", which should be sufficient for an average softsynth. :) tim
