jack is configured for 48khz, 24b, 128 sample buffers. this was deemed the best tradeoff of format, latency, processor efficiency. i believe the kernel overlay will support higher SR through clock ratio division but not 100% sure. its hard for me to imagine this being a great use of resources, but i suppose if you want to experiment with bandwidth-expanding algorithms it could help.
With a gig of RAM, how much is available for scripts and applications?
the built-in softcut buffer-manipulator use an arbitrary amount of RAM (set at compile time). currently it is set to use 16777216 32-bit frames, so ~65MB. top reports ~693MB unwired.
Do we have any demonstrations of the processing limits?
i’m not sure what a useful demonstration would look like. we are rolling back the use of supernova due to its instability on ARM/NEON. this means using scsynth, which is single-threaded so limited to a single 1.2GHz core. that’s still a lot of sinewaves.
built-in mixing, softcut and FX takes about one entire core in addition. this leaves another ~2 cores worth of headroom for the lua interpreter (should you choose to employ it) and for an additional DSP process if you want. (puredata, custom jack client, &c)
running all 4 cores at >75% or so may cause overheating and kernel faults.
hope that helps.