Hello
I have the following problem, regarding the pd launching command line :
"pd -jack -rt" works correctly
"pd -jack -lib xxx" works correctly too (xxx can be any pd-linux libraries ; these libraries were installed from the PlanetCCRMA site with apt-get)
pd -jack -rt -lib xxx" never works (pd does not start and you get a watchdog message signaling Pd in the console)
Is there a solution for using additional libraries in realtime mode ? Thanks you very much,
-j
pd -jack -rt -lib xxx" never works (pd does not start and you get a watchdog message signaling Pd in the console)
This is the anwser I got on the archive :
"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." (Miller Puckette)
Actually I was first wrong, as some libraries work on my computer with the "-rt" flag : Iemlib, zexy, chaos, Gem (so this one seems to work on Linux in realtime mode). Some others don't work, like fftease and vasp (wtachdog).
Sorry for the confusion
-j
Selon Thomas Grill gr@grrrr.org:
Some others don't work, like fftease and vasp (wtachdog).
Hi Julien, i would be interested under which circumstances these don't work. Do you have an example patch etc.?
It's only about the loading, and actually I was wrong, as it's only a problem of launching time -- just see this commentated "screenshot" :
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| [root@localhost j]# pd -jack -rt -lib vasp priority 2 scheduling enabled. memory locking enabled. priority 4 scheduling enabled. memory locking enabled. <------ here the whole linux system becomes very slow watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... <------ here the Pd windows begins to draw slowly watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... <------ here everything become normal again ; Pd seems to work normally
VASP modular 0.1.2
vector assembling signal processor (C)2002-2003 Thomas Grill
http://www.parasitaere-kapazitaeten.net
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I got the same situation with fftease. I first thought they didn't work because of the watchdog messages, but actually you just have to wait and the normal situation gets back after, say 10 seconds.
I use the PlanetCCRMA/RH9.0 distribution of Linux (with the PlanetCCRMA low-latency kernel), the sound card is a RME Hammerfall Multiface.
I hope this will help. If you need some more information, please ask me
Sorry but I didn't have the time to test your objects inside patches, if there's a later problem in use I will tell you.
-j
wild guess, but can this have something to do with not explicitly setting SCHED_OTHER when launching a thread from a SCHED_FIFO pd thread?
i encountered some problems with this, but i don't really understand what's going on..
On Tue, Sep 21, 2004 at 03:16:00AM +0200, julien.breval@tremplin-utc.net wrote:
Selon Thomas Grill gr@grrrr.org:
Some others don't work, like fftease and vasp (wtachdog).
Hi Julien, i would be interested under which circumstances these don't work. Do you have an example patch etc.?
It's only about the loading, and actually I was wrong, as it's only a problem of launching time -- just see this commentated "screenshot" :
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||| [root@localhost j]# pd -jack -rt -lib vasp priority 2 scheduling enabled. memory locking enabled. priority 4 scheduling enabled. memory locking enabled. <------ here the whole linux system becomes very slow watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... <------ here the Pd windows begins to draw slowly watchdog: signaling pd... watchdog: signaling pd... watchdog: signaling pd... <------ here everything become normal again ; Pd seems to work normally
VASP modular 0.1.2vector assembling signal processor (C)2002-2003 Thomas Grill
http://www.parasitaere-kapazitaeten.net
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
I got the same situation with fftease. I first thought they didn't work because of the watchdog messages, but actually you just have to wait and the normal situation gets back after, say 10 seconds.
I use the PlanetCCRMA/RH9.0 distribution of Linux (with the PlanetCCRMA low-latency kernel), the sound card is a RME Hammerfall Multiface.
I hope this will help. If you need some more information, please ask me
Sorry but I didn't have the time to test your objects inside patches, if there's a later problem in use I will tell you.
-j
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list
wild guess, but can this have something to do with not explicitly setting SCHED_OTHER when launching a thread from a SCHED_FIFO pd thread?
Good guess, i think, although then only vasp may be affected, not fftease which is normally not compiled with FLEXT_THREADS defined. Flext starts a helper thread at startup and sets a lower priority. I'm grateful for any advice how to avoid the watchdog hickups!
best greetings, Thomas
-
julien.breval＠tremplin-utc.net -
Thomas Grill -
Tom Schouten