fix-ardour-rt: patch the readers too, or a correct rig reports itself broken
The four patches fixed both WRITERS of Ardour's scheduling policy. Nothing
touched the readers, and that is the half that bites after the fix lands:
- `parvagues-protect --check` demands SCHED_FIFO of every target, so
Ardour at prio 0 would read UNPROTECTED forever and check() would exit
non-zero by design. Its exit code is what the gate, the Bridge and
gig-up believe, so a green rig would have shown a red Ardour all night
while burying the one signal worth having: is scsynth really covered?
- `perf-audio` still printed "Set Ardour (PID …) to real-time priority
80" and the same for every child, while deliberately doing neither.
check() now reads the target's own prio out of the TARGETS row, so prio 0
means "want the OOM shield, leave scheduling alone" and prints
`sched=SCHED_OTHER (oom shield only, by design)`. prio > 0 is untouched:
scsynth/90, sclang/85 and pipewire/95 are judged exactly as before.
Verified on copies of both root files, not on the originals:
- all 8 patches apply, both files still bash -n clean
- second --apply says "already applied" (the predicate had to name Ardour;
perf-audio says "real-time priority 80" about aseqdump too, which this
fix leaves alone, so the loose grep could never have been true)
- verdict truth table 8/8, including the two rows that matter: a shielded
Ardour on SCHED_OTHER is ok, and an UNSHIELDED one is still a fault
- the patched check() run against the live processes prints
`ok ardour[615285] oom_score_adj=-1000 sched=SCHED_OTHER (oom shield
only, by design)` where the old one would have said UNPROTECTED, and
still flags scsynth and sclang, which are genuinely uncovered right now
Same shape as this morning's preload bug, one file over: the emitter changed
and the checker did not, so the checker lied. It is worth saying once more
that it did not merely miss a fault — it invented one.
Showing
Please
register
or
sign in
to comment