On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja