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 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
