Re: [LAU] Concerning schedtool

On 04/19/2014 05:58 AM, Jonathan E Brickman wrote: That may be true for ALSA MIDI applications, but for jack applications using schedtool is plain wrong. You do not want to raise the priority of the application (think GUI or UI) itself. You only want the audio+midi i/o of an app to have realtime privileges. JACK does just that. With schedutils the GUI or application itself is be able to preempt audio I/O. You should have even better performance if you use schedtools only for applications that use alsa. And ideally just get rid of all native ALSA apps (most of the ones on your list do offer jack audio+midi), and use the new jack-0.124.1 instead of a2jmidid. Wow. If schedutils works around this, there must be something very odd on your system, but hey. whatever works :) I find the hack to use the dummy driver and always resample using zita-a2j highly questionable. The timing of the dummy driver is horrible. It just uses usleep() which waits _at_least_ the given time (not at most). It's amazing that zita-ajbridge manages flatten this all out without major distortion :) The 'clock-source' configuration is misleading. The given clock is only used for calculating the time of the last x-run and for the b0rked built-in midi-drivers. It is not used in the dummy driver. Anyway as last note: jack uses sched_FIFO which can only be preemted by a another FIFO process with at least the same priority. Your schedtool script uses sched_RR which can be preempted (context switch) by other RR task (round robin time quantum), which is why it actually works: Those apps still can't preempt jack. otherwise zita-j2a with a higher priority than jack would cause all kind of priority inversions. yuck. tl;dr: Rather get the new jack1 - with zalsa built it and a proper midi driver and forget about schedutils. 2c, robin