[PD] new raspberries

Chris Clepper cgclepper at gmail.com
Mon Feb 9 19:13:40 CET 2015


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 at 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 at gmail.com> wrote:
> > On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <msp at 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 at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150209/eee69a98/attachment-0001.html>


More information about the Pd-list mailing list