[PD] Gem on Raspberry pi 2

[Simon Wise]

On 14/03/15 20:28, Cyrille Henry wrote:
>
> hello,
>
> 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 
implemented.

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.

Simon