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.
> When I don't, about one in 20-30 keyhits (and also occasionally
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.
Linux-audio-user mailing list