Martijn Sipkema wrote: > >> 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. > >User space MIDI scheduling should run at high rt priority. If scheduling >MIDI events is not done at a higher priority than the audio processing >then it will in general suffer jitter at the size of the audio interrupt >period.
Jitter amounting to the length of time the audio cycle takes to compute, that is (which will obviously be less than the audio irq period in a usable configuration). Another reason to run MIDI behind audio: task switching and the cache invalidation it causes. If audio processing is interrupted 1024 times per second, audio performance *will* degrade, even more if many Jack clients (= separate processes) are involved. Not sure about the impact though. We definitely need some testing data here. >Using the RTC is not necessary when using firm-timers. If you're doing software MIDI through, you'll have to cancel the timer you've just set, which is bad. It gets worse when you have user functions that generate MIDI events at random. In this case I think the use of firm timers is not adequate. >Also, when doing hard real-time audio/MIDI, it is not possible to use >more than about 70% of the available CPU time and still get reliable >results. > >Would a library for requesting the preferred scheduling policy and priority >for a certain task be a good idea to improve cooperation between >applications? I'd leave it to the user, but I tend to expect a user to be savvy. tim
