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@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@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list