Bug#944589: gsequencer: stalls system
the system here sets RT for the applications without issue,
"$ pgrep -fa jack
1717 /usr/bin/jackdbus auto
$ chrt -a -p 1717
pid 1717's current scheduling policy: SCHED_OTHER
pid 1717's current scheduling priority: 0
pid 1959's current scheduling policy: SCHED_OTHER
pid 1959's current scheduling priority: 0
pid 1960's current scheduling policy: SCHED_FIFO
pid 1960's current scheduling priority: 25
pid 1961's current scheduling policy: SCHED_OTHER
pid 1961's current scheduling priority: 0
"
"
$ pgrep -fa ardour-5.12
7358 /opt/Ardour-5.12.0/bin/ardour-5.12.0
$ chrt -a -p 7358
pid 7358's current scheduling policy: SCHED_OTHER
..
pid 7415's current scheduling policy: SCHED_FIFO
pid 7415's current scheduling priority: 20
pid 7424's current scheduling policy: SCHED_FIFO
pid 7424's current scheduling priority: 71
"
the system does not show anything pulseaudio here,
"$ pgrep -fa pulseaudio
$
"
I do have alsarawjack set for applications that want to connect to jack,
so here alsa is already being used in this configuration. (~/.asoundrc)
The ags.conf file you provided was tested with and it still causes
failure even without jack and not configuring alsarawjack..
The rtkit-daemon.service is running, and limits.conf is set as it is
supposed to for @audio group..
The stall occurs with both a custom kernel as well as a bpo-stocked one
from debian.. both 5.2.x kernels..
Other applications can get their requested process/threads elevated to RT...
spotted on the ags website,
"systemd-run -p CPUAccounting=false -p MemoryAccounting=false -p
TasksAccounting=false -p IOAccounting=false -p BlockIOAccounting=false
--scope gsequencer"
would not make a difference because these would need be set specifically
for Debian(cgroups), and I suppose it is for the other mainstream
distributions as well.
ags was tried with various audio settings, different kernels- same error
message. the bug must be in ags because all other RT applications here
can be set with rt priority.
recap:: The stall occurs with both a custom kernel as well as a
bpo-stocked one from debian.. both 5.2.x kernels. The CPU is plenty
resourceful with 4-core "Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz" with
8 gigs ram. The ags software has caused more than 12 stalls. --
filesystem checks and other extra things were tried to see if it can
load past the plugin-loading stage.
If someone knows how to fix this, feel free to give it a look.
Reply to: