The IRMOS realtime scheduler

Quite well. Of course, nothing can work better than using the PC for doing exclusively (jack-enabled) audio, with jack (and client threads) running at real-time priority, with rt-priorities fine-tuned by hand (e.g., see http://subversion.ffado.org/wiki/IrqPriorities or, in case of more real-time applications, employing a rate-monotonic ordering), etc.

However, the interesting facts I can point out are the following:

1) the obtained Jack "driver end times" are basically similar to the ones of the configuration above, detailing:
1.a) when using soft resource reservations, we actually got similar driver end times with no xrun events;
1.b) when using hard resource reservations, a few jack xrun might occur in correspondence of abrupt workload changes (e.g., a software synthesizer) -- this is expected due to 2.b), and it can be mitigated by increasing the over-provisioning level;

2) the modified Jack (daemon and library) finds automatically the needed scheduling parameters and requires no modifications to the applications:
2.a) the period is set depending on the configured sampling frequency and buffer size;
2.b) the budget is dynamically adapted following the monitored workload, with a few heuristics for: providing a proper safety over-provisioning level, reacting to new jack clients registration, and reacting to xrun occurrence;

3) in presence of other real-time applications on the system, the achieved performance of both Jack and the other real-time applications (exploiting EDF-based scheduling with temporal isolation) can be investigated in isolation, and no cumbersome (for the end-user) priority tuning is needed.