Re: [Jack-Devel] JACK thread priorities on different OSes

Le 12 mai 2011 à 21:05, Devin Anderson a écrit :

> On Thu, May 12, 2011 at 1:22 AM, Stéphane Letz <[hidden]> wrote:
> 
>> 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, the
>> THREAD_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.
> 
> I'm not convinced that this is wrong in every case.  I think that
> giving the choice to the user and letting him/her determine the best
> process priority for his/her system is a good idea.  I think issuing a
> very obvious warning containing lots of capital letters when running
> in REALTIME_PRIORITY_CLASS is also a good idea. :)
> 
> The process priority is less important if MMCSS is available, but
> that's not always the case.  It's my understanding that many Windows
> pro audio users still use Windows XP.
> 
>> - 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..
> 
> I think the process should run in NORMAL_PRIORITY_CLASS by default,
> and that the process priority should be adjustable via a command line
> argument.
> 
> I'm not totally convinced it will improve the situation either, but,
> given that JACK 2 runs on Windows and is going to continue to run on
> Windows, I would like to see the situation improve as much as it
> possibly can.

But you see on the http://msdn.microsoft.com/en-us/library/ms685100(v=vs.85).aspx table that *only* process REALTIME_PRIORITY_CLASS will actually change the actual value of the THREAD_PRIORITY_TIME_CRITICAL right? But then *all threads* (even GUI ones...) of this process will by higher that any thread of *any* other lover priority process running on the machine... 

And the following is clearly written:

"You should almost never use REALTIME_PRIORITY_CLASS, because this interrupts system threads that manage mouse input, keyboard input, and background disk flushing. This class can be appropriate for applications that "talk" directly to hardware or that perform brief tasks that should have limited interruptions."

> 
>>> 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...
> 
> I mostly agree with you, but I think MMCSS does help the situation a
> bit.  When MMCSS is available, it should definitely be used, as it
> solves the problem with process priorities that you identified
> earlier; that is, that a higher process priority changes the priority
> of *every* thread instead of the changing the priority of the threads
> that need to have high priorities.
> 
> Some possible mappings using MMCSS:
> 
> PRIORITY_AUDIO: Task Name - "Pro Audio", AVRT_PRIORITY_HIGH
> PRIORITY_CALLBACK: no MMCSS, THREAD_PRIORITY_NORMAL
> PRIORITY_MIDI_TERMINAL: Task Name - "Pro Audio", AVRT_PRIORITY_CRITICAL

Using MMCSS in the appropriate manner will makes much more sense... I'll work more in that direction

> 
>>> 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...
> 
> I don't expect any miracles.  However, since JACK 2 is running on
> Windows, I would like to see Windows users get a fighting chance.
> 

And I really don"t think we can do better for XP users BTW.

Stéphane 

1305228065.29428_0.ltw:2,a <DFF97C1B-8B2A-4566-B157-DE617C1D3A3F at grame dot fr>