[PD] Gem on Raspberry pi 2
simonzwise at gmail.com
Sun Mar 15 04:11:53 CET 2015
On 14/03/15 20:28, Cyrille Henry wrote:
> Le 14/03/2015 10:14, Csaba Láng a écrit :
>> Hi Cyrille,
>> I guess nohow. Raspberry uses openGL ES, while the minimal dependence to GEM
>> is openGL.
> i've read somewhere that raspberry pi 2 are openGL compatible.
> (i'm not talking about the RPi 1)
RPi 2 have a very similar chip, just with 4 cores instead of 1, same old issues
and advantages. Apparently there is some support beyond Es, but not enough to
run gem and as not at all documented.
If you are experimenting with an RPi 2 then with audio the load balancing by
switching cores will add considerable latency (X-runs at latencies the RPi 1
handles fine). This is probably due to cache invalidation on a core switch, and
the time required to fetch everything again if the switch occurs at an
inopportune moment re buffers and deadlines. For low latency audio you will need
to use linux cpu affinity to always put the main pd process on a specific core,
this can also be achieved by the no-sleep flag in pd which sets pd to use
busy-waiting (I believe) so run continuously and fully occupy one core. There
may be advantages to either technique, no point sleeping a process if it owns
the core exclusively, but running 100% may also lead to heating issues and a
need to run at lower clock speeds... depending I guess on how the no-sleep is
This could prove useful if you are ready to manually split your processing
between separate pd patches and script the launching to achieve the cpu affinity
required. cpusets could help more, making a core (or three) dedicated
exclusively to a pd process each while the remaining core(s) run anything else.
Some have said there may be heating issues without load balancing, but the
devices are cheap so a shortened life probably isn't an issue, other heat
problems could arise ... maybe slow down the clock speed or add a decent heat
sink to the chip if you are playing with this option.
More information about the Pd-list