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 <b...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
