Re: [iiwusynth-devel] Re: [Swami-devel] update and todo list

[Tim Goetze]

Peter Hanappe wrote:

>On thing is to run with SCHED_FIFO. It is another thing to use 100%
>CPU. It's the latter that's a problem. One solution is to use two
>watchdog threads. If the audio thread has priority N, one watchdog
>thread gets priority N+1 and the other one gets priority N-1.
>
>The high priority watchdog verifies that the low priority watchdog
>still gets scheduled. If not, it means that the audio thread is
>hogging the CPU. The high priority watchdog can then ask the synthesizer
>thread to cut notes.

that's a nice scheme. i think it might also be efficient to simply 
measure the time the DSP loop takes. if we then compare it to the time
we have in total per audio cycle, we get a fairly accurate measurement
of how much cpu we're using (even if we're being preempted in the DSP 
loop, we still get a good idea i think).

>> besides, you really need mlock(2) for rt processes. 
>
>You mentioned that before. I just added mlock for the sample data.
>Since the sample data can easily take up 100Mb, it clearly runs the
>risk of getting swapped.

yes, i'm still thinking this may have caused the clicks markus
mentioned with that 148 MB font. have you had a chance to try 
that font yet?

>> you can compile
>> capability support into your kernel and make your app run as a normal
>> user with all it takes to do realtime. jack has incorporated support
>> for this. the downside is it isn't really straightforward, and your
>> users will need the same, or your back to square one.
>
>I need to read more about memory locking. Pushing it on the TODO stack.

can't say i do know all about it, and certainly not on non-linux. 
i lazily call mlockall (MCL_CURRENT | MCL_FUTURE) at the first 
opportunity and then forget about it. for my taste it would be
far too complicated to look at all the code and data segments and
decide which need locking and which not. did i mention i need more
RAM? ;)

if you want program changes to be executed immediately, there's no
alternative to this approach for iiwusynth i think.

if you'd accept a short delay, a different, slender approach might
be to map the respective samples from the sf2-file into memory and
lock them (you still need to touch them, mlock(2) only means 'never
swap this out' but not 'make sure this is paged in right now'). one
would need to do that in a separate thread though.

>> the link john lazzaro recently posted on lad was quite informative
>> (about OSX scheduling) -- seems they have a model where you say: this
>> thread needs to run as soon as possible when it's ready, but it will
>> only take a cpu slice of, say, 30%. you can even tell the scheduler
>> if you need a contiguous time slice, or if you just need a constant
>> 30% etc. 
>
>The nice thing about that model is that the scheduler can give a
>definite answer whether real-time is possible or not when a process
>requests real-time performance. It does so by analysis the periocities
>of the existing real-time task, their requested time-slices and so on.
>On the other hand, it's does guaratee that the process will stay within
>the announced boundaries. I don't know what the MACH kernel does if a
>process uses more CPU then initially given but it might be able to
>prevent the system from locking.

afai remember it does, but i don't remember how. 

cheers,

tim