3 Jun
2006
3 Jun
'06
10:25 p.m.
Sorry to be vague, basically, what I want to do is create a timer for
an "event" sequencer I'm writing (which I will use to write music
compositions, video, etc). I cannot find "event timers" that will
give me accuracy of less than 1ms, so I'm using a 1ms resolution event
timer and after that polling the time of day in order to get to the
time I want. I'm trying to achieve ~256-900 event clock "ticks" per
second and minimize jitter.
First off, if anyone has advice for implementing such a timer I'd
appreciate it, but second, I'm wondering how I can make my program
have "real time" priority such that when a signal is created by this
1ms resolution event timer my app is quickly made to respond to the
signal and so this can be done as a user, [using set_rlimits, pam or
what have you (this is what i was talking about in my first email)].
Also, as I figure missed ticks are probably inevitable, I'm trying to
figure out a way to make my program robust to missed clock ticks [so
that over time i am still on beat].
Thank you,
Alex Norman
On Fri, 02 Jun, 2006 at 01:06AM +0200, Jens M Andreasen spake thus:
On Thu, 2006-06-01 at 10:06 -0700, Alex wrote:
I think he meant: how you demand RT priority and what you should do
not to screw it up once you have it.
> > I figure I can just look at jack but it would be nice see some
> > tutorial, to learn what is actually happening/necessary, trade-offs,
> > etc.
> >
> > thanks,
> > Alex Norman Does anyone have a link to a reference about
making apps with real
time priority capabilities?
As such there is no difference between an RT app and a not RT app,
except that the former varity might not work as advocated .... 
5 Jun
5 Jun
12:12 p.m.
New subject: [linux-audio-dev] real time priority programming tutorial
Here is essentially the code I have been using for this purpose.
You don't necessarily need to use max priority for sp.sched_priority.
There may be better ways of doing this, I guess... if anyone sees if
I'm missing something. Seems to work, but has the disadvantage of
having to run under "sudo" to gain the priority.
I'm not 100% sure if the mlockall call is necessary.
void set_process_highpriority()
{
/* Lock memory for better realtime response */
mlockall(MCL_FUTURE | MCL_CURRENT);
/* Set realtime scheduler policy, with a high priority. */
sched_param sp;
sched_getparam(getpid(), &sp);
sp.sched_priority = sched_get_priority_min(SCHED_FIFO);
sched_setscheduler(getpid(), SCHED_FIFO, &sp);
if (sched_getscheduler(getpid()) != SCHED_FIFO)
printf
("Warning: Could not set realtime scheduler policy.
Servoloop may be slow.\n"
" Try running as superuser.\n");
}
2:40 p.m.
New subject: [linux-audio-dev] real time priority programming tutorial
Am Montag, 5. Juni 2006 16:12 schrieb Steve:
Here is essentially the code I have been using for
this purpose.
You don't necessarily need to use max priority for sp.sched_priority.
There may be better ways of doing this, I guess... if anyone sees if
I'm missing something. Seems to work, but has the disadvantage of
having to run under "sudo" to gain the priority.
Depends on your system configuration. I don't have to call it as super user on
my system.
I'm not 100% sure if the mlockall call is
necessary.
mlockall avoids memory swapping, so as long as you haven't completely turned
off swapping in your system it's definitely a good idea to call mlockall in a
RT sensitive process.
If you're not a C++ hater, here's a general purpose "Thread" class which
can
be used for RT threads and low priority threads as well:
http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/common/Thr…
http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/linuxsampler/src/common/Thr…
Just derive from that abstract "Thread" class and implement the virtual
method "int Main()" in your class.
CU
Christian
6542
days inactive
6544
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Alex -
Christian Schoenebeck -
Steve