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

PrevNext  Index
DateThu, 12 May 2011 00:01:25 -0700
From Devin Anderson <[hidden] at charityfinders dot com>
ToStéphane Letz <[hidden] at grame dot fr>
CcJack Developers <[hidden] at lists dot jackaudio dot org>
In-Reply-ToStéphane Letz Re: [Jack-Devel] Installers for Jack 1.9.8 (SVN 4384) for Windows 64 and 32 bits
Follow-UpStéphane Letz [Jack-Devel] JACK thread priorities on different OSes
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.

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.

> 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.

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

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

1305183703.7898_0.ltw:2,a <BANLkTi=S5MBkiEBTW7dPwtNi60Ji0ukMaA at mail dot gmail dot com>