Subject: [linux-audio-dev] Re: RFC: real-time design.
From: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: to maalis 18 1999 - 01:59:17 EST
Hi,
Since there doesn't seem to be very many answers, I would like to ask
another question:
What kind of a design you guys use in your real-time Linux sound
applications?
Then, some fine-tuning:
Andrew Clausen <clausen_AT_alphalink.com.au> writes:
> > // Get the current (system etc.) time in microseconds.
> >
> > unsigned int SF_Timer::get_time ();
>
> Yep. What do we do about over-flows? Does get_time() return how long sincethe timer was
Oops, you're right. 32 bits isn't enough. Perhaps we should use
POSIX timers, see clock_gettime() or timer_create(). There's a time_t for
seconds and a long for nano(!)seconds.
> Looks pretty good to me :-) I've been thinking about interruption from the kernel. Two
> main
> times this occurs:
>
> 1) Context switches. This can be avoid by calling:
> priority_level_struct.sched_priority = <something greater than 0>;
> sched_setsched(pid, SCHED_FIFO, &priority_level_struct);
>
> 2) Memory swapping. This can be done by page locking:
> mlock (ptr, size);
This is good. Only I think that the following POSIX functions should
be used: sched_setparam() or sched_setscheduler(). The mlock() is fine.
These functions can all be found on SGI IRIX 6.5, Sun Solaris and Digital UNIX
machines.
There's one more thing to take into account:
3) File I/O. This should be asyncronous, i.e. non-blocking.
> Both require root access. If Sonic Flow were to use these, there would have to be a lot of
>
> security features. Eg, a block could intentionally lock up the system. The sched_setsched
Would it be possible to release the root privileges after the call to
these functions?
There's some discussion on priorities on the IRIX man pages. Namely,
it is said that digital media applications need low latency response times
from the operating system and that changing interrupt thread behavior is
undesirable, i.e. that priority range 110...199 should be used.
-- -Jarno
This archive was generated by hypermail 2b28 : ma maalis 13 2000 - 11:59:35 EST