Re: [PATCH]sched: Isochronous class v2 for unprivileged soft rt scheduling

["Jack O'Quin" <joq@io.com>]

Con Kolivas <kernel@kolivas.org> writes:

> As for priority support, I have been working on it. While the test
> cases I've been involved in show no need for it, I can understand why
> it would be desirable.

Yes.  Rui's jack_test3.2 does not require multiple realtime
priorities, but I can point to applications that do.  Their reasons
for working that way make sense and should be supported.

For example, the JACK Audio Mastering interface (JAMin) does a Fast
Fourier Transform on the audio for phase-neutral frequency domain
crossover and EQ processing.  This is very CPU intensive, but modern
processors can handle it and the sound is outstanding.  The FFT
algorithm uses a moving window with a natural block size of 256
frames.  When the JACK buffer size is large enough, JAMin performs
this operation directly in the process callback.

When the JACK buffer size is smaller than 256 frames that won't work.
So, JAMin queues the audio to a realtime helper thread running at a
priority one less than the JACK process thread.  So, when JACK is
running at 64 frames per cycle (the jack_test3.2 default), JAMin's FFT
thread will have four process cycles in which to compute its next FFT
window.  This adds latency, but permits the application to work even
when the overall JACK graph is running at rather low latencies.  If
the scheduler were to run that thread at the same priority as the JACK
process thread, it would practically guarantee xruns.  This would
cause JAMin to be unfairly ejected from the JACK graph for failing to
meet its realtime deadlines.

So, there are legitimate examples of realtime applications needing to
use more than one scheduler priority.
-- 
  joq