I've not got any version of the rpi, but maybe it's scaling down the clock frequency of unused cores, which then takes some time to spin up to full speed when a task is moved by the kernel?
I also had issues on amd64 desktop and core2duo laptop with pd -rt not being taken into account by the kernel ondemand cpu speed governor, or some other issue perhaps, whereby the cpu speed would stay at ~800MHz even though it really needed to be higher to reduce xruns etc.. pd -nrt would scale up the cpu speed correctly.
On my quad-core amd64 desktop I run this before realtime work (or nrt benchmarking) to set all cores to maximum speed (with the 'performance' governor):
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g performance ; done
Then when I want to reduce fan noise / heat etc and I'm not doing much intensive, I reset to the default 'ondemand' governor:
for c in 0 1 2 3 ; do sudo cpufreq-set -c $c -g ondemand ; done
Might also be worth looking into setting scheduler cpu core affinity for pd, jackd, pd-gui, ... but I don't know how to do that.
Claude
On 06/02/15 21:38, katja wrote:
Aplay can play a .wav file without trouble, so it is not a general problem with the audio hardware or drivers on Pi 2b.
I installed command htop to see CPU load per core. It's interesting, the load switches from one core to another, and sometimes they all seem to be almost idle even with a heavy Pd patch running.