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 <katjavet...@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 <katjavet...@gmail.com> wrote: > > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <m...@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 >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list