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
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
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 claudiusmaximus@goto10.org:
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
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 <bernardobarros2@gmail.com
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 claudiusmaximus@goto10.org:
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
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
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
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 jamie@postlude.co.uk 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+portaudioTrouble 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 whenusing 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 whenusing 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
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:
- 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.
- 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.
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
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
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
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
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
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
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% AppleHDA NativeInt32ToFloat32_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% DspFuncLib iZRedist::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_kernel iokit_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% DspFuncLib iZRedist::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% DspFuncLib DspFuncNoiseCanceller::process(unsigned long, unsigned long)
0.0% 4.0% DspFuncLib DspFuncManager::process(void const*, void const*, unsigned long, unsigned long)
0.0% 4.0% AppleHDA AppleHDAEngine::convertInputSamples_StereoToStereo_32(void const*, void*, unsigned long, unsigned long, _IOAudioStreamFormat const*, IOAudioStream*)
0.0% 4.0% AppleHDA AppleHDAEngine::convertInputSamples(void const*, void*, unsigned long, unsigned long, _IOAudioStreamFormat const*, IOAudioStream*)
0.0% 4.0% IOAudioFamily IOAudioStream::readInputSamples(IOAudioClientBuffer*, unsigned long)
0.0% 4.0% IOAudioFamily IOAudioEngineUserClient::performClientInput(unsigned long, IOAudioClientBufferSet*)
0.0% 4.0% IOAudioFamily IOAudioEngineUserClient::performClientIO(unsigned long, unsigned long, bool, unsigned long, unsigned long, unsigned long)
0.0% 4.0% mach_kernel iokit_user_client_trap
0.0% 4.0% mach_kernel get_user_regs
0.0% 2.7% DspFuncLib iZRedist::DSP::FftImpl::InvFftReal(iZRedist::DSP::Cmplx*, float*) const
0.0% 0.0% DspFuncLib iZRedist::DSP::Fft::FftRealCcs(float const*, float*)
6.3% 6.3% DspFuncLib DspFuncHelper::process_IIR_xmm_LR(float*, float*, float*, float*, unsigned int)
0.0% 6.2% DspFuncLib DspFuncEQ::_equalizer(float*, float*, unsigned long)
0.0% 6.2% DspFuncLib DspFuncEQ::process(unsigned long, unsigned long)
0.0% 6.2% DspFuncLib DspFuncManager::process(void const*, void const*, unsigned long, unsigned long)
0.0% 4.3% AppleHDA AppleHDAEngine::clipOutputSamples(void const*, void*, unsigned long, unsigned long, _IOAudioStreamFormat const*, IOAudioStream*)
0.0% 4.3% IOAudioFamily IOAudioStream::clipOutputSamples(unsigned long, unsigned long)
0.0% 4.3% IOAudioFamily IOAudioStream::clipIfNecessary()
0.0% 4.3% IOAudioFamily IOAudioStream::processOutputSamples(IOAudioClientBuffer*, unsigned long, unsigned long, bool)
0.0% 4.3% IOAudioFamily IOAudioEngineUserClient::performClientOutput(unsigned long, unsigned long, IOAudioClientBufferSet*, unsigned long, unsigned long)
0.0% 4.3% IOAudioFamily IOAudioEngineUserClient::performClientIO(unsigned long, unsigned long, bool, unsigned long, unsigned long, unsigned long)
0.0% 4.3% mach_kernel iokit_user_client_trap
0.0% 4.3% mach_kernel get_user_regs
So we're spending 17% CPU calling get_user_regs()?
Jamie
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 jamie@postlude.co.uk wrote:
pd doing 'nothing':
10.6% 10.6% mach_kernel ml_set_interrupts_enabled 9.4% 9.4% DspFuncLibiZRedist::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% AppleHDA NativeInt32ToFloat32_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
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
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
On Sun, Nov 14, 2010 at 12:00 PM, Mathieu Bouchard matju@artengine.cawrote:
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.
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 jamie@postlude.co.uk 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% AppleHDA NativeInt32ToFloat32_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
On Mon, Nov 15, 2010 at 8:04 AM, Jamie Bullock jamie@postlude.co.uk 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.
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
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
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 matju@artengine.ca:
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
Seriously, use Jack, and watch the CPU usage drop significantly.
On Thu, Oct 28, 2010 at 1:06 PM, Bernardo Barros bernardobarros2@gmail.comwrote:
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 matju@artengine.ca:
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
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 zeeb.brandon@gmail.com wrote:
Seriously, use Jack, and watch the CPU usage drop significantly.
On Thu, Oct 28, 2010 at 1:06 PM, Bernardo Barros bernardobarros2@gmail.com 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 matju@artengine.ca:
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
-
Bernardo Barros -
brandon zeeb -
chris clepper -
Claude Heiland-Allen -
Hans-Christoph Steiner -
Jamie Bullock -
Mathieu Bouchard -
Roman Haefeli -
William Brent