Real-time priority

Micheal Allen Thompson mat0001 at
Tue Apr 6 23:44:44 CEST 1999


I run pd on my SGI under root for performance with the nice negative
values to increase its priority level, but only for performance
reasons... I had a 4 SGI installation pd/GEM running for 3 days without
a crash of IRIX or pd/gem. CPU usage ranged from %50 to %98 in some
cases. This could not run under normal usage... I also was using the SGI 
soft synth so that I could do 8 channel audio from my O2(and 3D graphics 
and audio processing).... (when can we see 8 channel audio on SGI?) 

Now I have been messing around with jMax/fts and it runs well... would pd
run as well under real-time system tunings? 

i like pd better than jMax... but fts does do audio real well. 


On Tue, 6
Apr 1999,
Guenter Geiger wrote:

> Hi Larry !
> Actually , when writing about solving the realtime scheduling problem,
> I was thinking about your proposal, which, I think you posted over
> a year ago on the list.
> With this solution it would be possible to reliably run pd under root.
> We could check the performance of the system and switch to normal
> scheduling, when we realize that pd uses more than, say 95% of the CPU.
> I found out, that with some Computer - Soundcard combinations, pd runs
> very well under root, but "clicks" when run as normal user.
> A reliable solution for high priority scheduling  should give us better
> performance,
> at least under Linux and SGI, so we should try to find a common solution for
> them.
> Guenter
> > -----Original Message-----
> > From: root at [mailto:root at]On Behalf Of Larry
> > Troxler
> > Sent: Thursday, April 01, 1999 5:42 PM
> > To: pd-list
> > Subject: Real-time priority
> >
> >
> > Hi, I haven't been using PD lately, but thought but the
> > recent messages
> > about running PD as root insterested me.
> >
> > I assume that PD grabs the Posix real-time scheduling algorhihm when
> > running as root.
> > Once, when playing around with the some other real-time audio code, I
> > was able to use a second thread as a sort of software watchdog.
> > The watchdog thread would run periodically, checking and clearing a
> > global flag that the audio thread would write everytime it
> > completed its
> > output generation loop. The watchdog thread ran one priority level
> > higher than the audio thread.
> >
> > This was a while ago, but I remember that the concept seemed
> > to work. Am
> > I missing something with this idea?
> >
> > Larry
> >
> > --  Larry Troxler --  lt at  --  Patterson, NY USA  --
> >

Michael A. Thompson 
Unix SysAdmin.  
[IRIX - NeXTStep - Linux] 
University of North Texas 
Center for Experimental Music and Intermedia
Office: (940) 565-2382

* Windows 95: n.  32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company, that can't stand 1 bit of

More information about the Pd-list mailing list