<div dir="ltr">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...</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 7, 2015 at 10:52 AM, katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">As an alternative to "pd -nosleep", "taskset 0x00000001 pd" (as per<br>
Simon Wise's suggestion) is another way to run puredata properly on<br>
Raspberry Pi model 2B. This sets 'CPU affinity' for pd to core 1 (you<br>
could set another core in hex format). Apparently the switching<br>
between cores is detrimental to pd's dsp process. Core affinity is a<br>
side effect of pd's -nosleep option, that is probably why both<br>
approaches work. The advantage of the taskset approach is that command<br>
top or htop still show realistic CPU load for the process (with "pd<br>
-nosleep" it shows as 100% all the time).<br>
<br>
Here is a way to make pd start in taskset consistently in LXDE:<br>
1 - create a new textfile ~/.local/share/applications/puredata.desktop<br>
2 - copy the text from /usr/share/applications/puredata.desktop into<br>
this new file<br>
3 - replace the string after "Exec=" with "taskset 0x00000001 pd %F"<br>
4- logout and login for the new setting to take effect<br>
<br>
Now you can start pd with 'CPU affinity' from the menu or by double<br>
clicking a patch. Not sure if this is the definitive solution, but at<br>
least it makes pd work without audio errors.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Katja<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Sat, Feb 7, 2015 at 10:39 AM, katja <<a href="mailto:katjavetter@gmail.com">katjavetter@gmail.com</a>> wrote:<br>
> On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <<a href="mailto:msp@ucsd.edu">msp@ucsd.edu</a>> wrote:<br>
>> Also try running "pd -nosleep", which sometimes persuades kernels to<br>
>> schedule the process differently :)<br>
><br>
> Indeed, "pd -nosleep" does the magic. Command htop shows hat the<br>
> kernel has 100% CPU time reserved on one core (fixed per session) for<br>
> pd -nosleep. Pd-gui runs on one of the other cores, alternating. The<br>
> audio is fine with no dropouts.<br>
><br>
> It is possible to start two instances of pd -nosleep, and get a core<br>
> reserved for each. The second instance finds the alsa device busy of<br>
> course, and this makes no sense in practice. Maybe the [pd~] object<br>
> can profit from the multicore processor.<br>
><br>
> I've checked current draw with the setup: Raspberry Pi + USB keyboard<br>
> + USB mouse + USB audio interface (iMic) together consume ~400 mA with<br>
> only the desktop running, and ~450 mA with pd -nosleep running idle or<br>
> with a CPU intensive patch. This indicates there is some frequency<br>
> scaling going on after all. I'll look into that again when there's<br>
> more info about the new Pi's config defaults and options.<br>
><br>
> Katja<br>
<br>
_______________________________________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</div></div></blockquote></div><br></div>