[PD] Pd 20% idle CPU usage on MBP
Hi, On my Macbook Pro (2.5 GHz Core 2 Duo), Pd's idle CPU usage is 15-20%. This is really high for an application in idle state. I get this regardless of the version of Pd I use -- I've tested with 0.42 and 0.43 latest. The load is in the server, the GUI CPU usage seems quite low. Does anyone know why this is? Is there anything that can be done to improve the situation? Jamie -- http://www.jamiebullock.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
Hi, On 28/10/10 16:41, Jamie Bullock wrote: Pd's idle CPU usage is 15-20%. Does anyone know why this is? probably a bug.. you could try using gdb and interrupting Pd to see where it is being busy, or some profiling tool (gprof or strace or shark (?) or something else). Is there anything that can be done to improve the situation? Try turning DSP on and then off again, maybe. Claude ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
I get this bug since 2005 on the mac... maybe related to a broad issue in gui<->pd communication? 2010/10/28 Claude Heiland-Allen : > Hi, > > On 28/10/10 16:41, Jamie Bullock wrote: >> >> Pd's idle CPU usage is 15-20%. >> Does anyone know why this is? > > probably a bug.. you could try using gdb and interrupting Pd to see where > it is being busy, or some profiling tool (gprof or strace or shark (?) or > something else). > >> Is there anything that can be done to improve the situation? > > Try turning DSP on and then off again, maybe. > > > Claude > > ___ > 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
Re: [PD] Pd 20% idle CPU usage on MBP
This thread comes up every year or two, try running Pd with JackOSX instead of having Pd communicate directly with OS X. You should see the Pd process decrease it's CPU usage significantly. My guess is it's a Pd-> PortAudio -> OS X thing. Cheers, ~Brandon On Thu, Oct 28, 2010 at 12:42 PM, Bernardo Barros wrote: > I get this bug since 2005 on the mac... > maybe related to a broad issue in gui<->pd communication? > > 2010/10/28 Claude Heiland-Allen : > > Hi, > > > > On 28/10/10 16:41, Jamie Bullock wrote: > >> > >> Pd's idle CPU usage is 15-20%. > >> Does anyone know why this is? > > > > probably a bug.. you could try using gdb and interrupting Pd to see > where > > it is being busy, or some profiling tool (gprof or strace or shark (?) or > > something else). > > > >> Is there anything that can be done to improve the situation? > > > > Try turning DSP on and then off again, maybe. > > > > > > Claude > > > > ___ > > 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 > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Thu, 28 Oct 2010, brandon zeeb wrote: This thread comes up every year or two, I'd say at least twice a year... I think I already wrote about it on pd-list this autumn, no...? But it's hard to search the archives about the frequency of that thread, as the keywords might not be consistent. I just know that the problem has existed for quite a few years and that I read about it on pd-list more than a handful of times. ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Thu, 28 Oct 2010, Bernardo Barros wrote: I get this bug since 2005 on the mac... maybe related to a broad issue in gui<->pd communication? You'd have to justify that. I don't think it can have to do with anything except the DSP engine and/or PortAudio (did anyone investigate this ?) ___ | Mathieu Bouchard -- Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
sorry for the speculation. I really did not go deeper into this, I just used linux and less pd. but 20%cpu is a serious bu anyway. 2010/10/28 Mathieu Bouchard : > On Thu, 28 Oct 2010, Bernardo Barros wrote: > >> I get this bug since 2005 on the mac... >> maybe related to a broad issue in gui<->pd communication? > > You'd have to justify that. I don't think it can have to do with anything > except the DSP engine and/or PortAudio (did anyone investigate this ?) > > ___ > | Mathieu Bouchard -- Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
Seriously, use Jack, and watch the CPU usage drop significantly. On Thu, Oct 28, 2010 at 1:06 PM, Bernardo Barros wrote: > sorry for the speculation. I really did not go deeper into this, I > just used linux and less pd. > but 20%cpu is a serious bu anyway. > > 2010/10/28 Mathieu Bouchard : > > On Thu, 28 Oct 2010, Bernardo Barros wrote: > > > >> I get this bug since 2005 on the mac... > >> maybe related to a broad issue in gui<->pd communication? > > > > You'd have to justify that. I don't think it can have to do with anything > > except the DSP engine and/or PortAudio (did anyone investigate this ?) > > > > ___ > > | Mathieu Bouchard -- Villeray, Montréal, QC > > ___ > 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
Re: [PD] Pd 20% idle CPU usage on MBP
I don't know if this point has been raised in past appearances of this issue, but for the record: I've noticed a drop to less than 10% idle when I'm running sound out of my MOTU 896 or Ultralite rather than built-in hardware. William On Thu, Oct 28, 2010 at 1:13 PM, brandon zeeb wrote: > Seriously, use Jack, and watch the CPU usage drop significantly. > > On Thu, Oct 28, 2010 at 1:06 PM, Bernardo Barros > wrote: >> >> sorry for the speculation. I really did not go deeper into this, I >> just used linux and less pd. >> but 20%cpu is a serious bu anyway. >> >> 2010/10/28 Mathieu Bouchard : >> > On Thu, 28 Oct 2010, Bernardo Barros wrote: >> > >> >> I get this bug since 2005 on the mac... >> >> maybe related to a broad issue in gui<->pd communication? >> > >> > You'd have to justify that. I don't think it can have to do with >> > anything >> > except the DSP engine and/or PortAudio (did anyone investigate this ?) >> > >> > ___ >> > | Mathieu Bouchard -- Villeray, Montréal, QC >> >> ___ >> 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 > > -- William Brent www.williambrent.com “Great minds flock together” Conflations: conversational idiom for the 21st century www.conflations.com ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On 28 Oct 2010, at 17:55, Mathieu Bouchard wrote: > On Thu, 28 Oct 2010, brandon zeeb wrote: > >> This thread comes up every year or two, > > I'd say at least twice a year... I think I already wrote about it on pd-list > this autumn, no...? But it's hard to search the archives about the frequency > of that thread, as the keywords might not be consistent. I just know that the > problem has existed for quite a few years and that I read about it on pd-list > more than a handful of times. Indeed! I remembered it coming up and so I searched the archives before posting, but keywords like 'cpu' and 'usage' don't do very much. However, digging a little with Shark, I see that a high proportion of Pd's CPU time is spent talking with the audio hardware, so I try Google: " DspFuncLib portaudio", and lo and behold: http://www.google.co.uk/search?q=DspFuncLib+portaudio Trouble is "use jack" doesn't solve the problem, it merely avoids it. So, zooming in a bit, I see at least two issues here: 1. there is a lot of activity in the underlying audio drivers when using the Portaudio driver on OS X, even when audio is off in the application. Let's call this the 'idle' CPU usage. IMO, this should be less than 1% on modern CPUs for well behaved applications. I've added this to the bug tracker. 2. there is a lot of activity in the underlying audio drivers when using the Portaudio driver on OS X, when audio is on in Pd. Comparison with AudioMulch, which also uses Portaudio suggests that is only in part a Portaudio problem. AudioMulch idles at ~10% on my machine. I suspect that the problem with Pd+portaudio may be due to a small buffer size used by Pd. I thought Pd's 'Delay' setting in audio preferences was supposed to handle this, but changing delay to 500ms, has no effect on CPU use. Also added to tracker. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
Great detective work! I'd love to see better CPU performance on OS X. Hopefully this also implies that one could see their Pd->Jack performance increase as well. Cheers, ~Brandon On Mon, Nov 1, 2010 at 7:31 AM, Jamie Bullock wrote: > > On 28 Oct 2010, at 17:55, Mathieu Bouchard wrote: > > > On Thu, 28 Oct 2010, brandon zeeb wrote: > > > >> This thread comes up every year or two, > > > > I'd say at least twice a year... I think I already wrote about it on > pd-list this autumn, no...? But it's hard to search the archives about the > frequency of that thread, as the keywords might not be consistent. I just > know that the problem has existed for quite a few years and that I read > about it on pd-list more than a handful of times. > > Indeed! I remembered it coming up and so I searched the archives before > posting, but keywords like 'cpu' and 'usage' don't do very much. > > However, digging a little with Shark, I see that a high proportion of Pd's > CPU time is spent talking with the audio hardware, so I try Google: " > DspFuncLib portaudio", and lo and behold: > >http://www.google.co.uk/search?q=DspFuncLib+portaudio > > Trouble is "use jack" doesn't solve the problem, it merely avoids it. > > So, zooming in a bit, I see at least two issues here: > >1. there is a lot of activity in the underlying audio drivers when > using the Portaudio driver on OS X, even when audio is off in the > application. Let's call this the 'idle' CPU usage. IMO, this should be less > than 1% on modern CPUs for well behaved applications. I've added this to the > bug tracker. > >2. there is a lot of activity in the underlying audio drivers when > using the Portaudio driver on OS X, when audio is on in Pd. Comparison with > AudioMulch, which also uses Portaudio suggests that is only in part a > Portaudio problem. AudioMulch idles at ~10% on my machine. I suspect that > the problem with Pd+portaudio may be due to a small buffer size used by Pd. > I thought Pd's 'Delay' setting in audio preferences was supposed to handle > this, but changing delay to 500ms, has no effect on CPU use. Also added to > tracker. > > Jamie > > > > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Nov 1, 2010, at 7:31 AM, Jamie Bullock wrote: On 28 Oct 2010, at 17:55, Mathieu Bouchard wrote: On Thu, 28 Oct 2010, brandon zeeb wrote: This thread comes up every year or two, I'd say at least twice a year... I think I already wrote about it on pd-list this autumn, no...? But it's hard to search the archives about the frequency of that thread, as the keywords might not be consistent. I just know that the problem has existed for quite a few years and that I read about it on pd-list more than a handful of times. Indeed! I remembered it coming up and so I searched the archives before posting, but keywords like 'cpu' and 'usage' don't do very much. However, digging a little with Shark, I see that a high proportion of Pd's CPU time is spent talking with the audio hardware, so I try Google: " DspFuncLib portaudio", and lo and behold: http://www.google.co.uk/search?q=DspFuncLib+portaudio Trouble is "use jack" doesn't solve the problem, it merely avoids it. So, zooming in a bit, I see at least two issues here: 1. there is a lot of activity in the underlying audio drivers when using the Portaudio driver on OS X, even when audio is off in the application. Let's call this the 'idle' CPU usage. IMO, this should be less than 1% on modern CPUs for well behaved applications. I've added this to the bug tracker. 2. there is a lot of activity in the underlying audio drivers when using the Portaudio driver on OS X, when audio is on in Pd. Comparison with AudioMulch, which also uses Portaudio suggests that is only in part a Portaudio problem. AudioMulch idles at ~10% on my machine. I suspect that the problem with Pd+portaudio may be due to a small buffer size used by Pd. I thought Pd's 'Delay' setting in audio preferences was supposed to handle this, but changing delay to 500ms, has no effect on CPU use. Also added to tracker. As far as I understand it, Pd only does the 20% idle thing when its not really doing anything. So if Pd is working hard, it'll stop spending 20% of the CPU idling. I could be wrong tho, and that would be worth profiling. That's the key point: is Pd efficient when its doing stuff, rather than whether it uses extra CPU when idling. .hc I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On 7 Nov 2010, at 18:36, Hans-Christoph Steiner wrote: > > As far as I understand it, Pd only does the 20% idle thing when its not > really doing anything. So if Pd is working hard, it'll stop spending 20% of > the CPU idling. I could be wrong tho, and that would be worth profiling. > That's the key point: is Pd efficient when its doing stuff, rather than > whether it uses extra CPU when idling. > - Pd uses X% of the CPU talking with audio drivers when it is idle (even if audio is off) - When the audio driver is portaudio Pd uses ~20% of the CPU talking with the driver (under OS X on a 2.5 GHz MBP) 2 separate problems, the second being the most pressing. And yes, ~20% is the base level, so as soon as you start adding processing, CPU load goes up from there... I don't think portaudio is that great for realtime work, although I think this is bordering on worst-case (compared to other apps). I've a feeling the problem might lie in the buffer size used for passing audio to portaudio. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On 8 Nov 2010, at 12:15, Jamie Bullock wrote: > > > I don't think portaudio is that great for realtime work, although I think > this is bordering on worst-case (compared to other apps). I've a feeling the > problem might lie in the buffer size used for passing audio to portaudio. > And I've just noticed that Pd uses the PABLIO (blocking I/O) interface to Portaudio. This might be part of the problem as it certainly isn't designed fo low-latency work. cf. http://music.columbia.edu/pipermail/portaudio/2002-March/000578.html Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Nov 8, 2010, at 7:25 AM, Jamie Bullock wrote: On 8 Nov 2010, at 12:15, Jamie Bullock wrote: I don't think portaudio is that great for realtime work, although I think this is bordering on worst-case (compared to other apps). I've a feeling the problem might lie in the buffer size used for passing audio to portaudio. And I've just noticed that Pd uses the PABLIO (blocking I/O) interface to Portaudio. This might be part of the problem as it certainly isn't designed fo low-latency work. cf. http://music.columbia.edu/pipermail/portaudio/2002-March/000578.html Jamie Another thing to try is Miller's new "callback" support. Its a checkbox in the audio settings. About this, I don't think anyone really thinks its good as it is, its just a matter of someone doing the work to improve it. The Jack support in Pd does seem to get a lot more work on it, so that's probably also a good reason why it works better. .hc If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it.- Thomas Jefferson ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Mon, 8 Nov 2010, Jamie Bullock wrote:
And I've just noticed that Pd uses the PABLIO (blocking I/O) interface
to Portaudio. This might be part of the problem as it certainly isn't
designed fo low-latency work.
But a blocking interface isn't using any extra CPU at all, so it sounds
like the 20 % is not because PABLIO is used. However, anything blocking
can prevent Pd from reaching the ceiling of 100 % CPU usage, because it
spends a certain % of time waiting for more input, but the way that this
is registered with the OS, the OS does not record this time as being used
by Pd, and instead tries to do something else in the meanwhile, and if it
can't, it records that time as being spent waiting for anyone to need the
CPU ("idle").
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Sun, 7 Nov 2010, Hans-Christoph Steiner wrote: As far as I understand it, Pd only does the 20% idle thing when its not really doing anything. So if Pd is working hard, it'll stop spending 20% of the CPU idling. It's not a real idle thing, it's a 20 % usage reported by 'top' while the user assumes that Pd shouldn't be doing anything. For example, you open pd, open no patches, and then 'top' reports 20 % usage and the computer gets a bit warmer than when Pd is not open. Can anyone run Apple Shark on this, so that we know what it is doing when it's doing that ? ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On 8 Nov 2010, at 20:45, Mathieu Bouchard wrote: > On Sun, 7 Nov 2010, Hans-Christoph Steiner wrote: > >> As far as I understand it, Pd only does the 20% idle thing when its not >> really doing anything. So if Pd is working hard, it'll stop spending 20% of >> the CPU idling. > > It's not a real idle thing, it's a 20 % usage reported by 'top' while the > user assumes that Pd shouldn't be doing anything. For example, you open pd, > open no patches, and then 'top' reports 20 % usage and the computer gets a > bit warmer than when Pd is not open. > > Can anyone run Apple Shark on this, so that we know what it is doing when > it's doing that ? > pd doing 'nothing': 10.6% 10.6% mach_kernel ml_set_interrupts_enabled 9.4%9.4%DspFuncLib iZRedist::DSP::Denoise::processWithLookahead(int, float* const*, int) 6.7%6.7%DspFuncLib iZRedist::DSP::FftImpl::FftComplex_InPlace(iZRedist::DSP::Cmplx*) const 6.3%6.3%DspFuncLib DspFuncHelper::process_IIR_xmm_LR(float*, float*, float*, float*, unsigned int) 3.8%3.8%DspFuncLib iZRedist::Util::Log(float) 2.8%2.8%AppleHDANativeInt32ToFloat32_X86 2.5%2.5%DspFuncLib iZRedist::DSP::FftImpl::FftReal(float const*, iZRedist::DSP::Cmplx*) const 2.3%2.3%DspFuncLib DspFuncDRC::_dynamicRangeControl(float*, float*, unsigned long, unsigned long) 2.0%2.0%mach_kernel lo_mach_scall Drilling down: 10.6% 10.6% mach_kernel ml_set_interrupts_enabled 0.0%4.3%mach_kernel thread_dispatch 0.0%3.0%mach_kernel thread_continue 0.0%0.9%mach_kernel semaphore_destroy 0.0%0.7%mach_kernel chudxnu_cpu_alloc 0.0%0.4%mach_kernel inval_copy_windows 0.0%0.4%mach_kernel fpnoextflt 0.0%0.3%mach_kernel semaphore_signal_internal 0.0%0.2%mach_kernel thread_call_enter1_delayed 0.0%0.2%mach_kernel wait_queue_unlink 0.0%0.1%mach_kernel wait_queue_sub_clearrefs 0.0%0.0%mach_kernel wait_queue_assert_wait 0.0%0.0%mach_kernel ast_taken 0.0%0.0%mach_kernel wait_queue_set_unlink_all 9.4%9.4%DspFuncLib iZRedist::DSP::Denoise::processWithLookahead(int, float* const*, int) 0.0%9.4%DspFuncLib iZRedist::DSP::Denoise::Process(float const* const*, unsigned int, unsigned int, float* const*, unsigned int) 0.0%9.4%DspFuncLibiZRedist::ANREngine::Process(unsigned int, float*) 0.0%9.4%DspFuncLib iZRedist::ANRProcess(iZRedist::ANREngine*, unsigned int, float*) 0.0%9.4%DspFuncLib DspFuncNoiseCanceller::process(unsigned long, unsigned long) 0.0%9.4%DspFuncLib DspFuncManager::process(void const*, void const*, unsigned long, unsigned long) 0.0%9.4%AppleHDA AppleHDAEngine::convertInputSamples_StereoToStereo_32(void const*, void*, unsigned long, unsigned long, _IOAudioStreamFormat const*, IOAudioStream*) 0.0%9.4%AppleHDA AppleHDAEngine::convertInputSamples(void const*, void*, unsigned long, unsigned long, _IOAudioStreamFormat const*, IOAudioStream*) 0.0%9.4%IOAudioFamily IOAudioStream::readInputSamples(IOAudioClientBuffer*, unsigned long) 0.0%9.4%IOAudioFamily IOAudioEngineUserClient::performClientInput(unsigned long, IOAudioClientBufferSet*) 0.0%9.4%IOAudioFamily IOAudioEngineUserClient::performClientIO(unsigned long, unsigned long, bool, unsigned long, unsigned long, unsigned long) 0.0%9.4%mach_kerneliokit_user_client_trap 0.0%9.4%mach_kernel get_user_regs 6.7%6.7%DspFuncLib iZRedist::DSP::FftImpl::FftComplex_InPlace(iZRedist::DSP::Cmplx*) const 0.0%6.6%DspFuncLib iZRedist::DSP::FftImpl::FftReal(float const*, iZRedist::DSP::Cmplx*) const 0.0%4.0%DspFuncLibiZRedist::DSP::Fft::FftRealCcs(float const*, float*) 0.0%4.0%DspFuncLib iZRedist::DSP::OversampledFilterbank::Decompose(float const* const*, int, float* const*, int, int) 0.0%4.0%DspFuncLib iZRedist::DSP::Denoise::processWithLookahead(int, float* const*, int) 0.0%4.0%DspFuncLib iZRedist::DSP::Denoise::Process(float const* const*, unsigned int, unsigned int, float* const*, unsigned int) 0.0%4.0%DspFuncLib iZRedist::ANREngine::Process(unsigned int, float*) 0.0%4.0%DspFuncLib iZRedist::ANRProcess(iZRedist::ANREngine*, unsigned int, float*) 0.0%4.0
Re: [PD] Pd 20% idle CPU usage on MBP
On 8 Nov 2010, at 15:45, Hans-Christoph Steiner wrote: > > Another thing to try is Miller's new "callback" support. Its a checkbox in > the audio settings. > That does improve things slightly, reducing CPU by about 3% to 17% on my MBP. By comparison, AudioMulch, which also uses PortAudio idles at around 5%. > About this, I don't think anyone really thinks its good as it is, its just a > matter of someone doing the work to improve it. The Jack support in Pd does > seem to get a lot more work on it, so that's probably also a good reason why > it works better. > Sure, and I feel like we're starting that work by doing some diagnostics. Jamie ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
Is this using the built-in speakers or the headphone jack? Plug in an optical cable and see if the CPU doesn't drop a lot. Or try a USB or Firewire interface. By default CoreAudio does a lot of processing on audio when using the built-in outputs. It used to mainly be limiting to keep the shitty speakers from blowing, but it has expanded over time. There is obviously a way to tell CoreAudio to cut that out, but how that is done via PortAudio is a question for the PA developers. The ml_set_interrupts_enabled is the blocking. On Tue, Nov 9, 2010 at 10:48 AM, Jamie Bullock wrote: > > > > pd doing 'nothing': > >10.6% 10.6% mach_kernel ml_set_interrupts_enabled >9.4%9.4%DspFuncLib > iZRedist::DSP::Denoise::processWithLookahead(int, float* const*, int) >6.7%6.7%DspFuncLib > iZRedist::DSP::FftImpl::FftComplex_InPlace(iZRedist::DSP::Cmplx*) const >6.3%6.3%DspFuncLib > DspFuncHelper::process_IIR_xmm_LR(float*, float*, float*, float*, unsigned > int) >3.8%3.8%DspFuncLib iZRedist::Util::Log(float) >2.8%2.8%AppleHDANativeInt32ToFloat32_X86 >2.5%2.5%DspFuncLib > iZRedist::DSP::FftImpl::FftReal(float const*, iZRedist::DSP::Cmplx*) const >2.3%2.3%DspFuncLib > DspFuncDRC::_dynamicRangeControl(float*, float*, unsigned long, unsigned > long) >2.0%2.0%mach_kernel lo_mach_scall > > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Tue, 9 Nov 2010, chris clepper wrote: By default CoreAudio does a lot of processing on audio when using the built-in outputs. It used to mainly be limiting to keep the shitty speakers from blowing, but it has expanded over time. There is obviously a way to tell CoreAudio to cut that out, but how that is done via PortAudio is a question for the PA developers. Why does it do that in the application instead of inside some daemon ? I mean, what if you run 3 sound apps at once, does it does the same transformation on three signals (or pairs of signals) before mixing them ? (I ask because, if that transformation is all linear, it's a waste) ___ | Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Sun, 2010-11-14 at 12:00 -0500, Mathieu Bouchard wrote: > On Tue, 9 Nov 2010, chris clepper wrote: > > > By default CoreAudio does a lot of processing on audio when using the > > built-in outputs. It used to mainly be limiting to keep the shitty > > speakers from blowing, but it has expanded over time. There is > > obviously a way to tell CoreAudio to cut that out, but how that is done > > via PortAudio is a question for the PA developers. > > Why does it do that in the application instead of inside some daemon ? I > mean, what if you run 3 sound apps at once, does it does the same > transformation on three signals (or pairs of signals) before mixing them ? > > (I ask because, if that transformation is all linear, it's a waste) Judging from my ears, the sound coming out of the MBP built-in speakers is dynamically processed. To me it sounds somewhat similar to the kind of processing that is applied to broadcast audio of radio stations before the signal goes on-air. Try turning on and off an [osc~] with a toggle. It sounds crisper than it normally would without processing. Actually, I don't think that this processing is applied to each source separately. Also, it would make more sense to apply it only to the mixed signal in order to avoid clipping, even if more than one source are set to maximum gain. Roman ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On 10 Nov 2010, at 04:39, chris clepper wrote: > Is this using the built-in speakers or the headphone jack? Plug in an > optical cable and see if the CPU doesn't drop a lot. Or try a USB or > Firewire interface. > OK, just tried my Edirol FA-66 firewire interface. CPU does indeed drop to 12%. Still that's a ridiculous overhead for simply talking to the audio hardware. > By default CoreAudio does a lot of processing on audio when using the > built-in outputs. It used to mainly be limiting to keep the shitty speakers > from blowing, but it has expanded over time. There is obviously a way to > tell CoreAudio to cut that out, but how that is done via PortAudio is a > question for the PA developers. > > The ml_set_interrupts_enabled is the blocking. > Does that mean that Mathieu was wrong earlier about the PABLIO interface not causing any significant overhead? Jamie > On Tue, Nov 9, 2010 at 10:48 AM, Jamie Bullock wrote: > > > > pd doing 'nothing': > >10.6% 10.6% mach_kernel ml_set_interrupts_enabled >9.4%9.4%DspFuncLib > iZRedist::DSP::Denoise::processWithLookahead(int, float* const*, int) >6.7%6.7%DspFuncLib > iZRedist::DSP::FftImpl::FftComplex_InPlace(iZRedist::DSP::Cmplx*) const >6.3%6.3%DspFuncLib > DspFuncHelper::process_IIR_xmm_LR(float*, float*, float*, float*, unsigned > int) >3.8%3.8%DspFuncLib iZRedist::Util::Log(float) >2.8%2.8%AppleHDANativeInt32ToFloat32_X86 >2.5%2.5%DspFuncLib iZRedist::DSP::FftImpl::FftReal(float > const*, iZRedist::DSP::Cmplx*) const >2.3%2.3%DspFuncLib > DspFuncDRC::_dynamicRangeControl(float*, float*, unsigned long, unsigned long) >2.0%2.0%mach_kernel lo_mach_scall > ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Mon, Nov 15, 2010 at 8:04 AM, Jamie Bullock wrote: > > OK, just tried my Edirol FA-66 firewire interface. CPU does indeed drop to > 12%. > > Still that's a ridiculous overhead for simply talking to the audio > hardware. > > A profile would show that the DSP functions are no longer taking CPU time. The remaining 10% is the blocking. > Does that mean that Mathieu was wrong earlier about the PABLIO interface > not causing any significant overhead? > I don't know much about PortAudio and PABLIO. The blocking call probably does come from how Pd uses PA. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Sun, Nov 14, 2010 at 12:00 PM, Mathieu Bouchard wrote: > > Why does it do that in the application instead of inside some daemon ? I > mean, what if you run 3 sound apps at once, does it does the same > transformation on three signals (or pairs of signals) before mixing them ? > Since I don't work at Apple I don't have the definitive answer to that. In a standard Shark trace time spent in drivers is charged to the userland app that initiates the calls. The DSP could very well be doing those transforms only once, but if Pd is the only app accessing the driver, the functions would only be in the Pd trace. The GPU driver work from the GL calls in GEM show up under Pd's process too. Fire up ITunes and see what happens to audio in the driver. ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] Pd 20% idle CPU usage on MBP
On Mon, 15 Nov 2010, Jamie Bullock wrote:
Does that mean that Mathieu was wrong earlier about the PABLIO interface
not causing any significant overhead?
Blocking IO doesn't cause overhead, it just causes blocking. It's a kind
of lock, just like how sending a message in Pd blocks the sender until the
receiving methods say that the processing is over ("return").
AFAIK, the worse it does, is limit the maximum amount of CPU that Pd's DSP
can use, because with blocking, it's like Pd's DSP is running on the same
CPU as the process that the sound is sent to, EVEN when they don't even
run on the same CPU.
But that CPU has to be spent somewhere. Switching to a non-blocking
interface doesn't reduce the amount of heat generated by your CPU. (it
might even increase it just a tiny bit, as it's more work to handle more
tasks that want to run at the same time... but that's much less than 1%).
___
| Mathieu Bouchard tél: +1.514.383.3801 Villeray, Montréal, QC
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
