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

[Tim Goetze]

Josh Green wrote:

>On Mon, 2002-06-03 at 02:31, 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?
>> 
>> tim
>
>Yeah, I understand the concepts of SCHED_FIFO, I just wish there was a
>better way to achieve high priority status without resorting to being
>root and risking the process running away with your entire machine. I
>would think someone would have come up with a solution by now, since the
>current state of things seems rather dirty. What happens when there is
>more than one SCHED_FIFO process?

the one with the higher priority wins. otherwise it does what it 
says: first in, first out. 

if a sched_fifo (or what other OSes call it) thread decides it must
use the cpu 100%, there's not much to do to stop it, on linux at
least, and afaik windows isn't better. it isn't dirty imo because
there is no other way to guarantee your task is only preempted for
serving interrupts. code that locks up the box is dirty ;)

>Perhaps the process 'nice' value could be used for such things. I'm
>curious how other Unix OSes handle latency critical applications and
>what APIs they provide. Anyways.. Just some thoughts. Lates..

i've tried 'nice' and it wasn't so nice; i reckon the linux scheduler
preempts other tasks in the middle of their timeslice in favour of 
your task only if you are running SCHED_FIFO or *_RR.

besides, you really need mlock(2) for rt processes. 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.

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. 

otoh i just read a comparison of different high-end audio cards on win
and OSX (c't magazine, not online afaik) that claimed minimum
latencies were worse on OSX. though this may be a driver thing
as well because OSX is relatively new (at least to those making these
cards).

tim