latest Pd-Extended cpu usage (was: new editing features of Pd-extended 0.43, now in beta)
Sorry about the double posting (and the first to a totally unrelated post), my send email searching skills are lacking today.
Anywho, the latest nightly build is still running at around 17% cpu for me before ever opening a patch. It's just enough to make my fans hum. :)
I've attached a process sample from Activity Monitor, hope it helps track it down.
Cheers, Rich
On Tue, Feb 21, 2012 at 1:16 AM, Rich E reakinator@gmail.com wrote:
One thing of concern however is the cpu usage when DSP is on and there are no patches open - Pd-0.43.1-extended-20120220 reports ~ 17% while Pd-0.43.1-vanilla reports 7%. What could be the cause of that?
Cheers, Rich
On Tue, Feb 28, 2012 at 7:12 PM, Rich E reakinator@gmail.com wrote:
Anywho, the latest nightly build is still running at around 17% cpu for me before ever opening a patch. It's just enough to make my fans hum. :)
I've attached a process sample from Activity Monitor, hope it helps track it down.
An interesting question. On my MacBook with OSX 10.5 Pd is sometimes running as much as 27% in 'idle' state. When Pd is started, dsp if off but the adc/dac are not. Only after turning dsp on, and off again, the adc/dac are off.
As you're on OSX, you can use the magnificent performance profiler Shark.app to get a better view of CPU load of functions. Most CPU time for adc/dac is consumed by DspFuncLib, AppleHDA and mach_kernel. Apparently, the system does a lot of processing on the audio stream without us asking for it. There's denoise, equalizer and fft functions amongst others. I don't think Pd can influence these routines, except by not using the adc/dac.
CPU load for adc/dac depends on hardware. Using an external audio interface reduces the load.
Katja
On 28 Feb 2012, at 19:58, katja wrote:
On Tue, Feb 28, 2012 at 7:12 PM, Rich E reakinator@gmail.com wrote:
Anywho, the latest nightly build is still running at around 17% cpu for me before ever opening a patch. It's just enough to make my fans hum. :)
I've attached a process sample from Activity Monitor, hope it helps track it down.
An interesting question. On my MacBook with OSX 10.5 Pd is sometimes running as much as 27% in 'idle' state. When Pd is started, dsp if off but the adc/dac are not. Only after turning dsp on, and off again, the adc/dac are off.
As you're on OSX, you can use the magnificent performance profiler Shark.app to get a better view of CPU load of functions. Most CPU time for adc/dac is consumed by DspFuncLib, AppleHDA and mach_kernel. Apparently, the system does a lot of processing on the audio stream without us asking for it. There's denoise, equalizer and fft functions amongst others. I don't think Pd can influence these routines, except by not using the adc/dac.
CPU load for adc/dac depends on hardware. Using an external audio interface reduces the load.
Yup, I think this is related to the Portaudio driver. I reported it here:
http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070
I don't think it's Portaudio itself that's at fault, but rather the way it interfaces with Pd.
best,
Jamie
On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock jamie@postlude.co.uk wrote:
Yup, I think this is related to the Portaudio driver. I reported it here:
http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=557...
I don't think it's Portaudio itself that's at fault, but rather the way it interfaces with Pd.
DspFuncLib is in:
/System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
If you run command nm on the lib, you'll see a plethora of dsp functions like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and whatnot. Functions in this lib are called when the internal soundcard is used. When using an external soundcard with Pd, DspFuncLib is not called and that makes the big difference in CPU load.
AppleHDA and mach_kernel are Apple libs as well and together with DspFuncLib they are responsible for the crazy CPU load in the 'idle-but-dsp-on' case.
PortAudio functions are apparently statically built into Pd and they consume very little CPU time.
Katja
On 28 Feb 2012, at 21:10, katja wrote:
On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock jamie@postlude.co.uk wrote:
Yup, I think this is related to the Portaudio driver. I reported it here:
http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070I don't think it's Portaudio itself that's at fault, but rather the way it interfaces with Pd.
DspFuncLib is in:
/System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
If you run command nm on the lib, you'll see a plethora of dsp functions like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and whatnot. Functions in this lib are called when the internal soundcard is used. When using an external soundcard with Pd, DspFuncLib is not called and that makes the big difference in CPU load.
AppleHDA and mach_kernel are Apple libs as well and together with DspFuncLib they are responsible for the crazy CPU load in the 'idle-but-dsp-on' case.
PortAudio functions are apparently statically built into Pd and they consume very little CPU time.
It seems that you're right, so I've closed the bug (my apologies to PortAudio!).
I guess the real 'fix' for this is that Pd now has a block size setting in Preferences. With a block size of 1024, using the PortAudio driver I get a CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce CPU. Here, I got a reduction of ~2% with that checked.
Also, I'm not sure if this is an improvement in recent versions of OS X, but Pd now runs at only ~5% with DSP on using the PortAudio driver with a blocksize of 64. This is on a MacBook Air i7/1.8.
best,
Jamie
Note that the issue I'm seeing is a difference in cpu usage between Pd-Extended and Pd-vanilla. In OS X 10.7, when opening up each version of pd and looking at Activity Monitor (before every opening a patch or turning on DSP), I get:
- Pd-0.43.1-extended-20120228 running at ~ 17% cpu
- Pd-0.43-1 running at ~ 7% cpu
I can file this on sourceforge if it would be easier to track there.
On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock jamie@postlude.co.uk wrote:
On 28 Feb 2012, at 21:10, katja wrote:
On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock jamie@postlude.co.uk
wrote:
Yup, I think this is related to the Portaudio driver. I reported it here:
http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=557...
I don't think it's Portaudio itself that's at fault, but rather the way
it interfaces with Pd.
DspFuncLib is in:
/System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
If you run command nm on the lib, you'll see a plethora of dsp functions
like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and whatnot. Functions in this lib are called when the internal soundcard is used. When using an external soundcard with Pd, DspFuncLib is not called and that makes the big difference in CPU load.
AppleHDA and mach_kernel are Apple libs as well and together with
DspFuncLib they are responsible for the crazy CPU load in the 'idle-but-dsp-on' case.
PortAudio functions are apparently statically built into Pd and they
consume very little CPU time.
It seems that you're right, so I've closed the bug (my apologies to PortAudio!).
I guess the real 'fix' for this is that Pd now has a block size setting in Preferences. With a block size of 1024, using the PortAudio driver I get a CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce CPU. Here, I got a reduction of ~2% with that checked.
Also, I'm not sure if this is an improvement in recent versions of OS X, but Pd now runs at only ~5% with DSP on using the PortAudio driver with a blocksize of 64. This is on a MacBook Air i7/1.8.
best,
Jamie
-- http://www.jamiebullock.com
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-extended uses a quite a bit more recent version of portaudio, but that seems to be making things worse here. That update helps in other things tho. This stuff is really not my specialty, so I'd appreciate help with it.
One thing i have seen is that using JackOSX makes the idle CPU usage go down to about 2%. I think JackOSX also bypasses all that Apple postprocessing.
.hc
On Feb 29, 2012, at 6:17 AM, Rich E wrote:
Note that the issue I'm seeing is a difference in cpu usage between Pd-Extended and Pd-vanilla. In OS X 10.7, when opening up each version of pd and looking at Activity Monitor (before every opening a patch or turning on DSP), I get:
- Pd-0.43.1-extended-20120228 running at ~ 17% cpu
- Pd-0.43-1 running at ~ 7% cpu
I can file this on sourceforge if it would be easier to track there.
On Wed, Feb 29, 2012 at 8:56 PM, Jamie Bullock jamie@postlude.co.uk wrote:
On 28 Feb 2012, at 21:10, katja wrote:
On Tue, Feb 28, 2012 at 9:06 PM, Jamie Bullock jamie@postlude.co.uk wrote:
Yup, I think this is related to the Portaudio driver. I reported it here:
http://sourceforge.net/tracker/?func=detail&aid=3100679&group_id=55736&atid=478070I don't think it's Portaudio itself that's at fault, but rather the way it interfaces with Pd.
DspFuncLib is in:
/System/Library/Extensions/AppleHDA.kext/Content/Plugins/DspFuncLib.kext/Contents/MacOS.
If you run command nm on the lib, you'll see a plethora of dsp functions like MultiBandCompressor, NoiseCanceller, Loudness, Softclip, Limiter and whatnot. Functions in this lib are called when the internal soundcard is used. When using an external soundcard with Pd, DspFuncLib is not called and that makes the big difference in CPU load.
AppleHDA and mach_kernel are Apple libs as well and together with DspFuncLib they are responsible for the crazy CPU load in the 'idle-but-dsp-on' case.
PortAudio functions are apparently statically built into Pd and they consume very little CPU time.
It seems that you're right, so I've closed the bug (my apologies to PortAudio!).
I guess the real 'fix' for this is that Pd now has a block size setting in Preferences. With a block size of 1024, using the PortAudio driver I get a CPU use of <2% with DSP on. Checking "use callbacks" also seems to reduce CPU. Here, I got a reduction of ~2% with that checked.
Also, I'm not sure if this is an improvement in recent versions of OS X, but Pd now runs at only ~5% with DSP on using the PortAudio driver with a blocksize of 64. This is on a MacBook Air i7/1.8.
best,
Jamie
-- http://www.jamiebullock.com
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
All mankind is of one author, and is one volume; when one man dies, one chapter is not torn out of the book, but translated into a better language; and every chapter must be so translated.... -John Donne
-
Hans-Christoph Steiner -
Jamie Bullock -
katja -
Rich E