[PD] -rt for whom?

[guenter geiger]

On Mon, 5 Jul 2004, Miller Puckette wrote:
> Pd effectively tries to make its main thread the "real-time" one.  If
> you stick hard-core computations in the main thread, as GEM does, this
> can have a bad effect on your machine.  THis is why "-rt" and GEM
> disagree with each other on OSX - and I suppose on linux as well although
> I don't know that.

My understanding was that currently it is simply not possible to do
non-trivial audio and video processing with pd at the same time. This
is because the video extensions do not have their own thread.
I think pdp has sort of an option to run in its own thread, but I don't
know how well this works, or how it is implemented.

The solution in general is to have two pd's running at the same time.
One doing the video using the -nosound flag and communicating with the
other one, with -rt which is doing the audio.

In theory, with Thomas Grills simple lock mechanism it should be possible
to change gem and pdp and put them into a separate thread.

Guenter

>
> cheers
> Miller
>
> On Mon, Jul 05, 2004 at 04:57:47PM -0500, chris clepper wrote:
> > On Jul 5, 2004, at 3:24 PM, Larry Troxler wrote:
> >
> > >On Monday 05 July 2004 13:57, chris clepper wrote:
> > >>A few notes about -rt mode:
> > >>
> > >>First, -rt is different on OSX compared to Linux.  On Linux, the flag
> > >>sets the priority of the pd process just like nice or renice
> > >
> > >Sorry if I somehow have a basic misunderstanding about how POSIX
> > >real-time
> > >scheduling works on Linux,  but I think  you're very wrong (or else the
> > >behavior of "nice" has changed a bit since the last time I researched
> > >it).
> >
> > I think you completely missed the point I was making, which concerns
> > the difference between the way processes are represented in the two
> > systems.  You may indeed be right that (re)nice won't do exactly the
> > same thing as calling the POSIX scheduling API, but the point is that
> > treating scheduling on OSX just like Linux is worthless because the
> > kernel looks at tasks and threads differently.  More to the point, Pd
> > has no actual real-time scheduling enabled on OSX, so the -rt flag is a
> > misnomer to begin with.  Real-time scheduling would be done using the
> > Mach kernel thread API as outlined in this document:
> >
> > http://developer.apple.com/documentation/Darwin/Conceptual/
> > KernelProgramming/scheduler/chapter_8_section_4.html
> >
> > The section under 'Using the Mach Thread API to Influence Scheduling'
> > contains the relevant info.  Setting priority to FIFO doesn't appear to
> > do anything at all related to 'real-time' scheduling.  By 'real-time' I
> > mean that exact amounts of time in cycles are set aside for a given
> > process per second and having the kernel agree to only do that task in
> > those cycles.  Just setting a high priority for a thread won't do that,
> > and also has some nasty side-effects as evidenced by GEM.  Again, this
> > is apparently completely and totally different from Linux 'real-time',
> > and implementations should reflect that.
> >
> >
> > _______________________________________________
> > PD-list mailing list
> > PD-list at iem.at
> > to manage your subscription (including un-subscription) see
> > http://iem.at/cgi-bin/mailman/listinfo/pd-list
>
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> to manage your subscription (including un-subscription) see
> http://iem.at/cgi-bin/mailman/listinfo/pd-list
>