[PD] new raspberries

Simon Wise simonzwise at gmail.com
Mon Feb 9 03:40:57 CET 2015


On 08/02/15 02:52, katja 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).

the nosleep option is perhaps a little better, if you have the other cores not 
fully utilised anyway, since it presumably replaces sleeps with busy waiting, so 
keeps one core busy with the audio process and avoids the slight delay that 
interrupts might cause, but really those are probably not significant in the 
time-scale of the audio latencies we are getting anyway.

Taskset certainly confirms that the problem was switching cores, and that is 
quite possibly a problem with losing the cache after a core switch.

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

the problem here would seem to be that ALL the pd processes now use that same 
core, and only that core ... so the gui processes and main pd processes will all 
be running on core 1 only .... want is wanted is that the main pd process uses 
that core while the gui processes uses the other cores. This launcher would be 
fine if running -nogui, but otherwise ...

taskset can set the affinity of a running process by its PID, so a script could 
do that for the audio process (after it was launched)

or an option could be added to pd which would call sched_setaffinity() when DSP 
is turned on, to set the affinity for the main pd process only.

or a cpuset could be defined and that PID allocated to it, which seems a simple 
process of defining a particular file in /proc then writing the PID to it, this 
has the advantage that that core can be reserved exclusively for the pd audio 
process.


I must investigate this further, as I do have some small multicore machines, and 
I would also like to be able to keep the audio and interfacing running smoothly 
and responsively on some bigger machines, while still being able to have plently 
of visualisation going on which might sometimes get choppy or slow if overloaded 
but that is isolated from the audio and critical interfacing.


Simon



More information about the Pd-list mailing list