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+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