Re: [Jack-Devel] JACK thread priorities on different OSes (Was: Installers for Jack 1.9.8...)

Le 13 mai 2011 à 18:08, Tommaso Cucinotta a écrit :

> Il 12/05/2011 08:20, David Nielson ha scritto:
>> On 05/12/2011 12:13 AM, Stéphane Letz wrote:
>>> 
>>> - 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.
> 
> For what it matters, this kind of model is the same that we need to exploit the deadline-based scheduler we're experimenting on Linux (presented during the last LAC): we identified the resource requirements of jackd and all of the involved client threads, in terms of how much computation-time is needed every period, and we've set-up parameters into the scheduler accordingly.
> AFAICS, currently this fComputation value is set-up statically to a random value ("500*1000"), or sometimes computed in a way I hope somebody can explain:
> 
>  driver->fEngineControl->fComputation = driver->fEngineControl->fPeriod * driver->fComputationGrain;

Well you are actually looking at JackCoreAudioDriver and this specific line is completely "experimental" and to say the truth, not used at all.

Here is the situation :

-  all periodic OSX RT threads are supposed to have a "period" and a "constraint" (which is actually the same value than "period" in all examples I've seen...), The "computation" value describe an "uninterruptible time slice" the RT thread will be allowed to use. (this is somewhat different from what you may find in Apple documentation, but is the result of discussion with Apple CoreAudio guys I had in past years)

Then this "uninterruptible time slice" is used to control correct thread interleaving, but in a quite ad-hoc manner at least for CoreAudio RT threads. Basically in CoreAudio they use a different "computation " value for the different buffer sizes with the following mapping:

64 frames ==> 500 usec
128 frames ==> 300 usec
256 frames up to 4096 ==> 100 usec

So the point is : a thread with a larger buffer size can afford to be interrupted often by another RT thread, (so lower computation value) but a thread with lover buffer size can't or lest often (so higher computation value)

For MIDI thread (CoreMIDI ones), again a very ad-hoc way : period = 0 computation = 250 constraint = 500

- audio RT client threads (the one started by libjack) take the values that are read in the server CoreAudio backend thread, so same value for all audio RT threads

- in dummy and net drivers, the values are setup "manually" (And I've just checked that the code is actually incorrect in SVN, I'll fix that ASAP)

> 
> Perhaps there's a chance to reuse a part of this deadline-based work on Linux also for setting up some more meaningful values on OS-X. However, that needs to be crossed with info about what the kernel actually does with those parameters. With Linux, that was easy: the whole set of threads were getting (at least) that required computation-time every period.

I don't see how the  period,  computation,  constraint , parameters can be used in a similar manner. There is not real notion of "reserved time slice" so to say.


> 
>>> Periodic tasks (like the audio ones) have to defines their period, MIDI task don"t need that (period = 0).
> 
> Probably I don't know much about how MIDI is coming in the loop: when are MIDI clients "polled" by Jack, as compared to the periodic main audio cycle ?

The point of audio/MIDI thread correct interleaving is on driver side (so in server process): audio and MIDI runs in different thread. I think Devin can explain better his design.

> If I have both a MIDI-enabled and an audio-enabled client, let's say a synthesizer (MIDI inputs and audio outputs), then does it have now 2 jack threads (one activated for processing MIDI the other for audio) ?
> 
No there is single thread on client side: MIDI events are aligned on a given audio frame, but have to be handled in the same RT thread.

Stephane 

1305304843.22688_0.ltw:2,a <3C35B251-022D-407E-BC88-97438BE98F6B at grame dot fr>