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@gmail.com> wrote:
> On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <msp@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