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 <[email protected]> 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 <[email protected]> wrote: > > > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <[email protected]> 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 > > > > _______________________________________________ > > [email protected] mailing list > > UNSUBSCRIBE and account-management -> > > http://lists.puredata.info/listinfo/pd-list > > _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
