>I think accurate MIDI timing eventually comes down on how well the >operating system performes. If Linux had a better performing nanosleep() >, i.e. if it would reprogram the clock chip to generate one shot interrupts >at the exact time the first ready thread will need to be woken up, then >the MIDI timing would be close to what the hardware is able to obtain.
Just want to say that I agree with this entirely. I'm a little pessimistic about Linus accepting KURT-like patches, given what he said last time. But he has changed his mind about other things, so you never know. >I don't think a new clock would make much sense. You could just run >the kernel with a higher clock resolution I think. Well, the overhead of the system timer interrupt is ever-present. If you use a different h/w clock for MIDI scheduling, its not there all the time. This can be useful for some systems/setups. >I disagree. Just use POSIX realtime clocks on a good kernel. You just >happen to need a realtime kernel for MIDI. And then there will still >be jitter in a dense MIDI stream, since a message takes about 1ms to >transmit. whats a good kernel? do you mean with HZ=1000 ? >That's a problem with the kernel then. BeOS could do this. Linux could >probably too without too much modification. The scheduling latency is >good enough with the latency/preemptive kernel patches. It is just the >clock resolution that is a little low. I agree (though from what Andrew Morton has said, the preemptive patches aren't really a big contribution to bounded latency). --p
