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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds