Hi all,
I've been experiencing a problem with running pd -rt -jack for some time now. After starting pd I get:
watchdog: signaling pd...
and of course pd doesn't respond to any commands. At some point I thought the problem was gone but it isn't.
I experienced this with recent 0.37 releases from Miller and from CVS (today I checked the latest tarball from Miller and did a CVS update). The interesting aspect of it is that if I run pd from within the releases's bin directory it behaves correctly. The above behaviour partains only to the version installed system-wide and only with the -rt -jack switches together.
my system: Mandrake 9.1, gcc 3.2.2, Mdk multimedia kernel 2.4.21, jack version 0.93.6, tcl/tk 8.3
I have seen a mention of this behaviour that had something to do with tk8.4 but it was working for me until recently. Perhaps it's only misconfiguration on my side?
I will be grateful for any ideas.
-- ./MiS _ __ __ (_)___ Michal Seta / / \ _/^ _| / V |_ \ @creazone.32k.org (___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
Hallo, Michal Seta hat gesagt: // Michal Seta wrote:
I experienced this with recent 0.37 releases from Miller and from CVS (today I checked the latest tarball from Miller and did a CVS update). The interesting aspect of it is that if I run pd from within the releases's bin directory it behaves correctly.
Probably this one isn't suid root, so it cannot run with higher priority.
I also have the same problem with -rt/-jack and in the end just don't run Pd with Jack anymore: either Pd's timing is bad (no -rt), or Jack and Pd clash over who's turn it is now, and one of both is giving up.
ciao
Frank Barknecht _ ______footils.org_
On Sun, 18 Jan 2004, Michal Seta wrote:
Hi all,
I've been experiencing a problem with running pd -rt -jack for some time now. After starting pd I get:
watchdog: signaling pd...
and of course pd doesn't respond to any commands. At some point I thought the problem was gone but it isn't.
Hi,
I couldn't reproduce until now, because my SBLive has a minimum latency setting of 512 samples.
Now, using the playback only trick I got down to 256 and ... I have the same behaviour.
I had this problem fixed in CVS once, but it seems that it got changed back, but it is quite easy to fix:
in s_inter.c, in the function sys_set_priority(int higher) change the line
p3 = (higher ? p2 - 1 : p2 - 3);
to
p3 = (higher ? p1 + 3 : p1 + 1);
.. let me know if it works
Thanks for reporting,
Guenter
PS: I will update the CVS as soon as sourceforge lets me.
I experienced this with recent 0.37 releases from Miller and from CVS (today I checked the latest tarball from Miller and did a CVS update). The interesting aspect of it is that if I run pd from within the releases's bin directory it behaves correctly. The above behaviour partains only to the version installed system-wide and only with the -rt -jack switches together.
my system: Mandrake 9.1, gcc 3.2.2, Mdk multimedia kernel 2.4.21, jack version 0.93.6, tcl/tk 8.3
I have seen a mention of this behaviour that had something to do with tk8.4 but it was working for me until recently. Perhaps it's only misconfiguration on my side?
I will be grateful for any ideas.
-- ./MiS _ __ __ (_)___ Michal Seta / / \ _/^ _| / V |_ \ @creazone.32k.org (___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Hi,
Yes, this seems to be working fine. Thanks!
./MiS
guenter geiger geiger@xdv.org writes:
p3 = (higher ? p2 - 1 : p2 - 3);
to
p3 = (higher ? p1 + 3 : p1 + 1);
.. let me know if it works
On Mon, 19 Jan 2004, Michal Seta wrote:
Yes, this seems to be working fine. Thanks!
Good to hear that. Seems that this change got lost during some merge of millers version back into CVS. Merging is really clumsy with CVS ..
Guenter
./MiS
guenter geiger geiger@xdv.org writes:
p3 = (higher ? p2 - 1 : p2 - 3);
to
p3 = (higher ? p1 + 3 : p1 + 1);
.. let me know if it works
-- _ __ __ (_)___ Michal Seta / / \ _/^ _| / V |_ \ @creazone.32k.org (___/V___|_|___/ http://www.%5Bcreazone%5D%7C%5Bnoonereceiving%5D.32k.org
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
Is it certain this doesn't affect behavior when "jack" is not being used? If so I can put it in my version -- if not, perhaps I should detect whether jack is installed.
Unfortunately, one can't switch back and forth between RT priorities except at startup (because you have to shed root permission then.)
cheers Miller
Hi,
I couldn't reproduce until now, because my SBLive has a minimum latency setting of 512 samples.
Now, using the playback only trick I got down to 256 and ... I have the same behaviour.
I had this problem fixed in CVS once, but it seems that it got changed back, but it is quite easy to fix:
in s_inter.c, in the function sys_set_priority(int higher) change the line
p3 = (higher ? p2 - 1 : p2 - 3);
to
p3 = (higher ? p1 + 3 : p1 + 1);
.. let me know if it works
Thanks for reporting,
Guenter
PS: I will update the CVS as soon as sourceforge lets me.
On Mon, 19 Jan 2004, Miller Puckette wrote:
Is it certain this doesn't affect behavior when "jack" is not being used? If so I can put it in my version -- if not, perhaps I should detect whether jack is installed.
According to the description of sched_setscheduler the priority is used to determine which process to run next. Normal processes with scheduling policy SCHED_OTHER have priority 0. SCHED_FIFO processes have higher priority, and under Linux it is likely that pd will be the only process in this group, and therefore it will have precedence. In this case it is of no use to give it higher priority than 1, because 1 will be the highest.
If JACK is running, pd's priority will be lower than JACK's. Which is how it should be.
So, the change should not affect normal realtime behaviour.
Guenter
Unfortunately, one can't switch back and forth between RT priorities except at startup (because you have to shed root permission then.)
cheers Miller
Hi,
I couldn't reproduce until now, because my SBLive has a minimum latency setting of 512 samples.
Now, using the playback only trick I got down to 256 and ... I have the same behaviour.
I had this problem fixed in CVS once, but it seems that it got changed back, but it is quite easy to fix:
in s_inter.c, in the function sys_set_priority(int higher) change the line
p3 = (higher ? p2 - 1 : p2 - 3);
to
p3 = (higher ? p1 + 3 : p1 + 1);
.. let me know if it works
Thanks for reporting,
Guenter
PS: I will update the CVS as soon as sourceforge lets me.
According to the description of sched_setscheduler the priority is used to determine which process to run next. Normal processes with scheduling policy SCHED_OTHER have priority 0. SCHED_FIFO processes have higher priority, and under Linux it is likely that pd will be the only process in this group, and therefore it will have precedence. In this case it is of no use to give it higher priority than 1, because 1 will be the highest.
If JACK is running, pd's priority will be lower than JACK's. Which is how it should be.
So, the change should not affect normal realtime behaviour.
Guenter
well, now it's pd and jack ... in the future, there's no telling how crowded the space of "real-time" hungry processes will get. So maybe it's worth finding a general way to determine which level Pd should live at. Perhaps it should be just below the one jack chooses (and does anyone know that one?)
Miller
On Mon, 19 Jan 2004, Miller Puckette wrote:
well, now it's pd and jack ... in the future, there's no telling how crowded the space of "real-time" hungry processes will get. So maybe it's worth finding a general way to determine which level Pd should live at. Perhaps it should be just below the one jack chooses (and does anyone know that one?)
seems to be 10 for the server and 9 for the client. (from jackd/jackd.c:static int realtime_priority = 10;)
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Mon, 19 Jan 2004, Miller Puckette wrote:
well, now it's pd and jack ... in the future, there's no telling how crowded the space of "real-time" hungry processes will get. So maybe it's worth finding a general way to determine which level Pd should live at. Perhaps it should be just below the one jack chooses (and does anyone know that one?)
seems to be 10 for the server and 9 for the client. (from jackd/jackd.c:static int realtime_priority = 10;)
BTW: If I'm right, Ardour, which started all the Jack craze, doesn't seem to elevate its own priority anymore at all, it just lets the Jack daemon put and pull data when Jack sees fit. But I may not be right. At least, /usr/bin/ardour here isn't setuid anything special.
ciao
Frank Barknecht _ ______footils.org__
On Mon, 19 Jan 2004, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Mon, 19 Jan 2004, Miller Puckette wrote:
well, now it's pd and jack ... in the future, there's no telling how crowded the space of "real-time" hungry processes will get. So maybe it's worth finding a general way to determine which level Pd should live at. Perhaps it should be just below the one jack chooses (and does anyone know that one?)
seems to be 10 for the server and 9 for the client. (from jackd/jackd.c:static int realtime_priority = 10;)
BTW: If I'm right, Ardour, which started all the Jack craze, doesn't seem to elevate its own priority anymore at all, it just lets the Jack daemon put and pull data when Jack sees fit. But I may not be right. At least, /usr/bin/ardour here isn't setuid anything special.
Pd is a different case, because adding proper jack support would require to change several things in the engine - the way its done now, high priority is a must.
Guenter
guenter geiger writes:
On Mon, 19 Jan 2004, Frank Barknecht wrote:
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
On Mon, 19 Jan 2004, Miller Puckette wrote:
well, now it's pd and jack ... in the future, there's no telling how crowded the space of "real-time" hungry processes will get. So maybe it's worth finding a general way to determine which level Pd should live at. Perhaps it should be just below the one jack chooses (and does anyone know that one?)
seems to be 10 for the server and 9 for the client. (from jackd/jackd.c:static int realtime_priority = 10;)
Since jack triggers a callback it should be higher priority (which is as a realtime priority in the new kernel 2.6.0 a lower number 1..99 for realtime which is mapped to 20-N, effective 140-N on 2.6.0 with the priority library call, to talk about he same numbers).
But also I saw clients priority number: res->realtime_priority = engine->rtpriority - 1; in engine.c of jackd
which means jack itself makes a client call (callback) one less than jack, so pd should be at least 2 less than jack, so that the callback always has priority to pd.
mfg winfried
-
Frank Barknecht -
guenter geiger -
Michal Seta -
Miller Puckette -
Winfried Ritsch