The only thing I can do is to allow the user to configure AGS_RT_PRIORITY http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/audio/thread/ags_audio_loop.c?h=3.0.x&id=93bddce14d8b1bf98f30867babd9d36db1487fbf#n660
regards, Joël On Thu, Nov 28, 2019 at 6:21 AM westlake <westlake2...@videotron.ca> wrote: > > It looks like I needed to do a reboot to verify the RT-bandwidth cap at > the 500000 limit for kernel.sched_rt_runtime_us in sysctl.. so "top" > shows gsequencer at 200% (when ags is set with 'jack') > > 500000 is about half rt period of 1 second(1000000), and so 200% on this > computer means it is half the cpu bandwidth on a 4-core machine I'm > using.. so this confirms the application is still saturating the RT > bandwidth. > > 500000/1000000 = 50% > 200/400% = 50% > > If you have a 2-core system, then saturation in the output of "top" > would be saying "100%" because the maximum cpu-bandwidth capacity is > 200% for 2 cores. > > By default, the cap-protection for RT-bandwidth is set at 950000.. I was > curious to see if sysctl's setting of kernel.sched_rt_runtime_us was > effective.. > > I've only known the basics, and I suppose there's something verifying > for me here as well, I'm pretty confident I've been learning about RT > things correctly as I've been setting up ardour+jack to work effectively.. > > maybe someone from debian team can help with the scheduling call things.. > > unfortunately I wouldn't be able to mentor coding specifics, but I know > it has something to do with schedule functions. > > good luck.. >
