Interesting. Of course, it _should_ be thermally permitted to run all cores at speed - and the Pi folk are taking heat dissipation very seriously in their thinking. So my leaning would be to risk $35 on a week-long stress test using -nosleep. Hmm, time to order a machine...
cheers Miller
On Mon, Feb 09, 2015 at 01:13:40PM -0500, Chris Clepper wrote:
The ARM multicore CPUs tend to bounce processes between cores to avoid thermal issues (an idle core is a cool core). If you really want to do -nosleep for a long period, think about adding a heatsink to the chip. I have had A9s lock up or shutdown pretty quickly from heat. On the plus side, I have lower latency on ARM than my new Macbook Air or any other desktop I run Pd on...
On Sat, Feb 7, 2015 at 10:52 AM, katja katjavetter@gmail.com wrote:
As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per Simon Wise's suggestion) is another way to run puredata properly on Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you could set another core in hex format). Apparently the switching between cores is detrimental to pd's dsp process. Core affinity is a side effect of pd's -nosleep option, that is probably why both approaches work. The advantage of the taskset approach is that command top or htop still show realistic CPU load for the process (with "pd -nosleep" it shows as 100% all the time).
Here is a way to make pd start in taskset consistently in LXDE: 1 - create a new textfile ~/.local/share/applications/puredata.desktop 2 - copy the text from /usr/share/applications/puredata.desktop into this new file 3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F" 4- logout and login for the new setting to take effect
Now you can start pd with 'CPU affinity' from the menu or by double clicking a patch. Not sure if this is the definitive solution, but at least it makes pd work without audio errors.
Katja
On Sat, Feb 7, 2015 at 10:39 AM, katja katjavetter@gmail.com wrote:
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list