[Jack-Devel] JACK thread priorities on different OSes

Le 12 mai 2011 à 09:01, Devin Anderson a écrit :

> On Wed, May 11, 2011 at 11:13 PM, Stéphane Letz <[hidden]> wrote:
> 
>> We can certainly makes thing clearer at JACK implementation level,
>> define some enum, but the point is to see if we can then find a  suitable
>> "mapping" to the real stuff on each system:
>> 
>> - I'm really not sure touching the "process" priority class on WIndows
>> with the -P value
>> (http://msdn.microsoft.com/en-us/library/ms685100(v=vs.85).aspx) is the
>> way to go, since (AFAICS) it touches *all threads* in the given process,
>> and this is not what we want.
> 
> Given that Windows has different process priorities, why shouldn't the
> user be able to set JACK's process priority in order to find the best
> way for JACK to operate on his/her system?
> 
> I'm not sure this is an argument for not allowing the user to set a
> process priority, given that I'm proposing that threads would still
> receive relative priorities based on the jobs they're performing (i.e.
> the critical MIDI thread would still have a higher priority than the
> audio thread, which would still have a higher priority than the
> callback thread, and so forth ...).  The process priority is an
> absolute value, and the thread priority values change relative to the
> process priority.
> 
> Ignoring MMCSS for a moment, there are two basic thread priority
> values a thread can have in JACK 2: THREAD_PRIORITY_NORMAL (if a
> thread doesn't request realtime) and THREAD_PRIORITY_TIME_CRITICAL (if
> a thread does request realtime) ... with nothing in between.  This
> makes it impossible to create differences in realtime priorities in
> threads.

Look at the table at the bottom of http://msdn.microsoft.com/en-us/library/ms685100(v=vs.85).aspx (the "Base priority")

Basically the way I understand is:

- in *any* process priory class, theTHREAD_PRIORITY_TIME_CRITICAL (currently used for audio and MIDI RT) is actually 15

- the only way to boost that value is to move the *entire process* to REALTIME_PRIORITY_CLASS but then *all other threads* of this process will get crazy values between 16 and 31, that is *above* any THREAD_PRIORITY_TIME_CRITICAL value that a process *below* REALTIME_PRIORITY_CLASS would have taken... this is just wrong.

- in the presence of MIDI and audio thread, what should we do? keep the process in NORMAL_PRIORITY_CLASS , set the audio RT to THREAD_PRIORITY_HIGHEST (so actually 10) and the MIDI RT to THREAD_PRIORITY_TIME_CRITICAL (so actually 15). Not sure it will improve the situation..
> 
> MMCSS, when it's implemented, adds another sort of priority when the
> -P switch is set to 90 or above.
> 
> I can't help but feel that the current situation is hackish and cheap.

So my feeling is that this process/thread priority description is basically flawed on Windows, and this is probably the reason they added another flawed concept like MMCSS...

> 
>> We would want to setup what happens for the RT thread (Audio,
>> possibly MIDI...) only and not the others ones.
> 
> Yes, but what about the differences in priority between the audio and
> MIDI threads?
> 
>> - concerning OSX: as I said there is no priority setting in the RT class. But this
>> is more "reservation" like approach, Basically a period, a "uninteruptible
>> computation grain", and a "constraint" (which is basically equals to the period.
>> Periodic tasks (like the audio ones) have to defines their period, MIDI task don"t
>> need that (period = 0). Then the "uninteruptible computation grain", is the way
>> to "control" RT thread interleaving, but this is done in a quite ad-hoc way
>> Basically CoreAudio guys have defined different values of this computation
>> grain for the different buffer sizes, and that is all!
>> 
>> What JACK2 does is just to *read* the values that the CoreAudio audio thread
>> is using (so on server side), and just use use them on client side for all RT
>> audio threads. So that all RT audio threads in the JACK context share the
>> same setting, which makes sense since they are all running at the same buffer
>> size. The MIDI thread have a specific setting (see JackCoreMidiOutputPort::Init()),
>> again by just looking at what CoreMIDI does, and using the same values....
> 
> I see potential mappings to start with:
> 
> PRIORITY_AUDIO: the values taken from the CoreAudio audio thread
> PRIORITY_MIDI_TERMINAL: the values CoreMIDI uses
> 
> :)
> 
> I can think of a potential practical use for this sort of thing.
> Let's assume that someone wanted to write an audio driver for bindings
> that were available on more than one operating system (i.e.
> PortAudio), or wanted to write a MIDI driver for bindings that were
> available on more than one operating system (i.e. PortMIDI, RtMidi).
> Instead of creating a bunch of ugly #ifdef's, the driver could use the
> appropriate constant to set the thread priority.

Sure I agree with that, I'm just saying we can improve a bit (abstract some OS specificities) but not expect miracles...

Stéphane 

1305188573.17421_0.ltw:2,a <DCB47670-0D77-4E86-8FDC-EB64DF113F4A at grame dot fr>