Re: [Jack-Devel] Installers for Jack 1.9.8 (SVN 4384) for Windows 64 and 32 bits

On Wed, May 11, 2011 at 2:54 AM, Stéphane Letz <[hidden]> wrote:

> That seems a good "theoritical" idea, but I'm still not sure it can be done
> in practice.

Right now, save for Linux, thread priorities aren't really *used* in
practice, or the way that it is done is sub-par.

On Windows, if the priority is >= 90 and MMCSS is available (Vista,
Windows 7), then an MMCSS priority is set; otherwise, the thread is
set with a priority of 'THREAD_PRIORITY_TIME_CRITICAL':

    http://trac.jackaudio.org/browser/jack2/trunk/jackmp/windows/JackWinThread.cpp#L201

... meaning that when a thread requests a priority of 90 or above, it
*might* have a priority that's higher than other threads, or it might
just have the same thread priority as every other thread that asks for
a realtime priority, which defeats the purpose of having thread
priorities, since JACK 2 doesn't deal with Windows process priorities.

On OSX, the priority you request doesn't even figure into the what happens:

    http://trac.jackaudio.org/browser/jack2/trunk/jackmp/macosx/JackMachThread.cpp#L188

There is, however, an OS-specific method you can call to set thread
parameters called 'SetParams':

    http://trac.jackaudio.org/browser/jack2/trunk/jackmp/macosx/JackMachThread.cpp#L222

... which has a usage that isn't exactly clear.

Currently, the only platform for which the current thread priority
implementation makes sense is Linux.  Even then, it isn't really clear
when a thread should request a certain priority in JACK.  There's no
documentation suggesting that, for example, if you're writing a MIDI
driver and you want your hardware output thread(s) to be able to
deliver MIDI messages via hardware with reasonably accurate timing,
then you should set your thread priority in this or that manner.

What I'm suggesting is that the thread priorities in JACK 2 be changed
so that they accept a priority related to the type of job the thread
will do:

enum JackThreadPriority {
   // JACK audio thread
   PRIORITY_AUDIO,
   // JACK callbacks
   PRIORITY_CALLBACK,
   // JACK MIDI thread that communicates directly with hardware
   PRIORITY_MIDI_TERMINAL,

   // More priorities here ...
};

... or maybe a constant that suggests what sort of priority is necessary:

enum JackThreadPriority {
    PRIORITY_LOW,
    PRIORITY_NORMAL,
    PRIORITY_HIGH,
    PRIORITY_CRITICAL,
    // More priorities here ...
};

... and that the underlying OS implementation does the right thing
with the given thread priority.

> The thing is that on each system JACK2 runs on, the
> underlying scheduling system is different, especially for real-time
> threads. POSIX system (Linux, Solaris) are probably the most flexible
> (with a precise setup of priority), but on OSX there is only a single class
> for RT threads and RT thread interleaving can be "somewhat" controled.
> On Windows the situation seems even worse, and I still don't know if
> there is a way to setup different classes of RT threads, and control
> thread interleaving the correct way. The situation is maybe only:
> Windows in not an OS suitable for "hard" RT stuff...

Regardless of whether or not Windows is not a suitable OS for RT stuff
(and I certainly don't believe it is), I think that a system like this
could be used to try to make things as usable as possible.

Here's a brief idea for Windows thread priorities:

1.) Alter the -P switch to set the *process* priority instead of the
realtime thread priorities.
2.) Map job priorities to Windows thread priorities:

    PRIORITY_AUDIO: THREAD_PRIORITY_HIGHEST
    PRIORITY_CALLBACK: THREAD_PRIORITY_NORMAL
    PRIORITY_MIDI_TERMINAL: THREAD_PRIORITY_TIME_CRITICAL

    ... etc.

These values might not be the correct values, but they can be tweaked
to do the right thing on Windows.

On Linux, you might map priority constants relative to the -P switch value:

    PRIORITY_AUDIO: P
    PRIORITY_CALLBACK: P - 1
    PRIORITY_MIDI_TERMINAL: P + 1

I don't understand OSX's 'thread_policy_set' function, but I'm sure
something similar can be done.

I think a system like this would make it easier and clearer to set
priorities for JACK 2 threads.

-- 
Devin Anderson
devin (at) charityfinders (dot) com

CharityFinders - http://www.charityfinders.com/
synthclone - http://synthclone.googlecode.com/

1305163900.13146_0.ltw:2,a <BANLkTikVyyrU3YguzpbuqexUAfT=NC8LQg at mail dot gmail dot com>