[PD] new raspberries

[Miller Puckette]

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 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
> >