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
Hi Ben,
AFAIK Pd doesn't have -rt on anything except Linux.
Core Audio + Pd doesn't run too smooth anyways, I would try it with JACK.
HTH, D.
On 3/7/10 7:25 AM, B. Bogart wrote:
Are there versions of pd-extended for OSX where -rt works? How do I set it.
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
On Mar 7, 2010, at 8:16 AM, 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.
Same values for me with same hardware running 10.6.2 and Pd-extended 0.41.4.
After using Pd on Linux for some years, I was expecting to experience the dreaded OSX "slow pd and midi syndrome". So far I haven't had any problems of the sort and my patches run just as they do in Linux with -rt. Of course I'm not using GEM and I'm not running 20 other applications at once as most mac users seem to do ...
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
-- William Brent www.williambrent.com
“Great minds flock together” Conflations: conversational idiom for the 21st century
www.conflations.com
Dan Wilcox danomatika.com robotcowboy.com
Hi Dan,
are you saying you run Pd on OSX with an -rt flag, or that running it on OSX is like running it with an -rt flag on Linux?
I've had a chance to compare identical patches on identical hardware (Powerbook G4 w/ OSX 10.4 and Gentoo) and I have to say I got a *lot* more processing power on Gentoo, upwards of 25% increase. That could have something to do with a leaner OS of course...
Best, Derek
On 3/7/10 2:03 PM, Dan Wilcox wrote:
After using Pd on Linux for some years, I was expecting to experience the dreaded OSX "slow pd and midi syndrome". So far I haven't had any problems of the sort and my patches run just as they do in Linux with -rt.
On Mar 7, 2010, at 1:16 PM, Derek Holzer wrote:
are you saying you run Pd on OSX with an -rt flag, or that running it on OSX is like running it with an -rt flag on Linux?
I've had a chance to compare identical patches on identical hardware (Powerbook G4 w/ OSX 10.4 and Gentoo) and I have to say I got a *lot* more processing power on Gentoo, upwards of 25% increase. That could have something to do with a leaner OS of course...
Well, I have been using the -rt flag out of habit, but I don't know if it makes a difference on OSX.
How do you define "processing power"? It's quite a relative term. Sure, you can squeeze every transistor for what it's worth using Gentoo but I don't care. All I know is Pd runs the same patches on OSX with the same capability as Ubuntu on my old (now kaput) Thinkpad. I have not spent much time in investigating how much cpu Pd takes on OSX since, so far, it hasn't been an issue ... which is great. I'd rather focus on making patches, not making Pd work well.
For what it's worth, I always develop with my performance hardware and OS in mind: PentiumIII 500Mhz running Ubuntu command line install. No realtime kernel required, only pd -rt using Alsa. I play live music with a guitar and peripherals and there isn't much difference to me between 2ms and 12ms latency for what I do. In other words, I focus on making minimal, fast patches.
And please, I don't wish to engage in a "this OS is better" argument. It would be interesting, however, to develop some tests and get feedback from various OS users on different capabilities aka timing precision, midi latency, audio latency, etc. I'm sure this has probably been done already though.
On 3/7/10 2:03 PM, Dan Wilcox wrote:
After using Pd on Linux for some years, I was expecting to experience the dreaded OSX "slow pd and midi syndrome". So far I haven't had any problems of the sort and my patches run just as they do in Linux with -rt.
Dan Wilcox danomatika.com robotcowboy.com
Hi Dan,
OS war wasn't my intention. Finding out if the -rt flag on OSX was. FWIW, I got very fed up with being a systems administrator instead of making instruments and sounds, and haven't booted the Gentoo partition in at least two years now...
D.
On 3/7/10 2:35 PM, Dan Wilcox wrote: =
And please, I don't wish to engage in a "this OS is better" argument.
On Mar 7, 2010, at 1:38 PM, Derek Holzer wrote:
Hi Dan,
OS war wasn't my intention. Finding out if the -rt flag on OSX was. FWIW, I got very fed up with being a systems administrator instead of making instruments and sounds, and haven't booted the Gentoo partition in at least two years now...
Hah, well you know exactly what I mean then.
I don't really know if the -rt flag does anything on OSX. Since the OS does audio mixing in the kernel through CoreAudio (from what I know), I assume it's not as relevant? I only got the mac last summer, so my experience has only been with 10.5 for 2 weeks then 10.6 from then on.
Dan Wilcox danomatika.com robotcowboy.com
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
-nosleep seems to have solved the issue.
I'm now getting the right numbers for [delay] in [realtime].
.b.
B. Bogart wrote:
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
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
B. Bogart -
Dan Wilcox -
Derek Holzer -
William Brent