Hi,
I believe that the -rt flag is still ignored in extended version 0.42.5. To debug this, I am using my own version of ps which lists the threads and also RTPRIO priorities: ps -eLo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio
Depending on your kernel settings, it might be harder for you to verify this, but I imagine you might find in the source code where it parses "flags" in .pdextended that it simply doesn't check for -rt.
If I start pd with -rt specified neither in ~/.pdextended nor on the command line, I get these priorities: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1299 TS - 0 19 19.8 RLl pd 1299 TS - 0 19 0.0 SLl pd 1299 FF 57 - 97 2.1 SLl pd 1299 TS - 0 19 0.0 SLl pd
but if I start with -rt "flags" field of ~/.pdextended I get the same realtime priority for all the pd threads! PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1263 TS - 0 19 23.3 RLl pd 1263 TS - 0 19 0.0 SLl pd 1263 FF 57 - 97 1.8 SLl pd 1263 TS - 0 19 0.0 SLl pd (I even tried putting -rt in two different places in "flags")
However, if I start using -rt on the command line I get the following priorities, for which all of the pd threads have at least RTPRIO 6: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1237 FF 6 - 46 30.9 SLl pd 1237 FF 6 - 46 0.0 SLl pd 1237 FF 57 - 97 1.1 SLl pd 1237 FF 6 - 46 0.0 SLl pd and then I don't get dropouts anymore. So for me, it is essential to use this option.
For the time being, my workaround is simply to put this shell script in ~/bin to add -rt to the flags every time the user calls pd: #!/bin/bash # # Shell script to make pd always start with -rt, no matter what # the user types. /usr/bin/pd -rt $*
Warm regards!
- Edgar
PS. See also: http://lists.puredata.info/pipermail/pd-list/2006-08/041087.html
Hey Edgar,
Try a nightly beta build of 0.43, I think this should be fixed:
http://autobuild.puredata.info/auto-build/latest/
.hc
On Feb 23, 2012, at 4:49 PM, Edgar Berdahl wrote:
Hi,
I believe that the -rt flag is still ignored in extended version 0.42.5. To debug this, I am using my own version of ps which lists the threads and also RTPRIO priorities: ps -eLo pid,class,rtprio,ni,pri,pcpu,stat,comm --sort -rtprio
Depending on your kernel settings, it might be harder for you to verify this, but I imagine you might find in the source code where it parses "flags" in .pdextended that it simply doesn't check for -rt.
If I start pd with -rt specified neither in ~/.pdextended nor on the command line, I get these priorities: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1299 TS - 0 19 19.8 RLl pd 1299 TS - 0 19 0.0 SLl pd 1299 FF 57 - 97 2.1 SLl pd 1299 TS - 0 19 0.0 SLl pd
but if I start with -rt "flags" field of ~/.pdextended I get the same realtime priority for all the pd threads! PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1263 TS - 0 19 23.3 RLl pd 1263 TS - 0 19 0.0 SLl pd 1263 FF 57 - 97 1.8 SLl pd 1263 TS - 0 19 0.0 SLl pd (I even tried putting -rt in two different places in "flags")
However, if I start using -rt on the command line I get the following priorities, for which all of the pd threads have at least RTPRIO 6: PID CLS RTPRIO NI PRI %CPU STAT COMMAND 1237 FF 6 - 46 30.9 SLl pd 1237 FF 6 - 46 0.0 SLl pd 1237 FF 57 - 97 1.1 SLl pd 1237 FF 6 - 46 0.0 SLl pd and then I don't get dropouts anymore. So for me, it is essential to use this option.
For the time being, my workaround is simply to put this shell script in ~/bin to add -rt to the flags every time the user calls pd: #!/bin/bash # # Shell script to make pd always start with -rt, no matter what # the user types. /usr/bin/pd -rt $*
Warm regards!
- Edgar
PS. See also: http://lists.puredata.info/pipermail/pd-list/2006-08/041087.html _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Access to computers should be unlimited and total. - the hacker ethic
-
Edgar Berdahl -
Hans-Christoph Steiner