I'm not doing any audio, just Gem rendering.
I did not have a chance to try -nosound (or is it -noaudio) anyhow I'll give that a try next time.
On a machine with multiple CPUs I expect all the OS stuff to end up on one CPU, and PD using up a whole one, meaning that timing should be tight until nearly 100% cpu. Since I'm having problems around 60%, hard to say what is up.
I'm using the same pd-extended.
Hans, Miller, does -rt do anything on OSX??
.b.
William Brent wrote:
Hi Ben,
For what it's worth, I just tested a patch running steady at 85% with 0.41.4-extended, and realtime reliably gives me values between 992-1008ms for a [delay 1000]. This is on a 2.5Ghz Intel Core 2 Duo, 4GB, OS 10.5.8.
On Sat, Mar 6, 2010 at 10:25 PM, B. Bogart ben@ekran.org wrote:
Hey all,
I've been running a patch on an intel mac for a while, but noticed some horrid timing problems [delay 1000] takes ~3000ms according to [realtime]. The patch uses between 50% and 105% CPU according to top.
I've not got it down to about ~1500ms, but I can't pull back the patch any further, and top says it using only 50-64% CPU...
I realized I was not using -rt, but when I try and run pd-extended (sorry I don't recall the version, probably the stable one as of Sept 2009) pd does not start in -rt mode, I get no messages from stdout or the console like I do in linux to tell me about priority scheduling.
Are there versions of pd-extended for OSX where -rt works? How do I set it.
I tried:
-rt in "startup flags"
sudo /Application/Pd-extended/.../bin/pd -rt
sudo su /Application/Pd-extended/.../bin/pd -rt
And nothing works.
So what have I missed? Or what Pd should I be using?
Thanks, B. Bogart
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list