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

[Peter Hanappe]

Tim Goetze wrote:
> Josh Green wrote:
> > > > Yes, performance seems like the most major issue for me. I am currently
> > > > using a 366mhz PII laptop and I have no trouble in maxing out my CPU. I
> > > > was also just reminded again today that running Swami/iiwusynth as root
> > > > is a bad idea. I connected up my little loop sequencer program via the
> > > > ALSA sequencer and started to crank the tempo up. Computer totally
> > > > frozen, not even SysRq keys would work, still audible noises emitting
> > > > though :)  I'm just glad I'm using ext3 journaling. Are there any better
> > > > ways of getting low latency audio without the perils of SCHED_FIFO?
> > > no, you can't do without SCHED_FIFO. it's the only way of ensuring
> > > your process is capable of processing promptly and frequently. without
> > > it, when the audio interface fires an interrupt and your process
> > > is marked ready to run in kernel, it is just one among a random
> > > number of processes contending for cpu. therefore the time it takes
> > > until your process actually gets to deliver data to (or fetch from) 
> > > the audio interface is not determinate in SCHED_NORMAL.
> > >
> > > occasionally i manage to lock up this box in SCHED_FIFO and SysRq
> > > hasn't failed me yet. strange it does this to you. have you checked
> > > it works at all?

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.

I've put it on the todo list.


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


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


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

Cheers,
Peter

> tim
>
>
> _______________________________________________
> iiwusynth-devel mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/iiwusynth-devel