Wow. This is getting interesting again ! Thank you Katja for purchasing and testing the new version so quickly.
Pierre.
2015-02-07 15:22 GMT+01:00 katja katjavetter@gmail.com:
10 ms buffer in audio settings was tested OK for this setup:
Raspberry Pi model 2B Raspbian wheezy, latest image from raspberrypi.org LXDE desktop running iMic USB audio interface, 2 in 2 out puredata 0.46-2 built from Raspbian jessie source on RPi model 2B pd started with option -nosleep, and running 'PicoJockey'
PicoJockey is a live sampling tool with effects. I've been using it as a Raspberry Pi test since the first 256 MB model B, for which it was too difficult, considering the USB troubles at the time. PicoJockey can be found here compiled on single core Raspi but the build works for model 2B too: http://www.katjaas.nl/slicejockey/slicejockey.html (page bottom). On model B+ I used to run PicoJockey at half the default sample rate to save CPU time, but with model 2B it can run at default sample rate while leaving some CPU headroom. PicoJockey's GUI controls are pretty CPU intensive but that's where the extra cores are useful.
Results are quite promising and there may be options for optimization, like compiling Pd with NEON instructions enabled (if gcc can do that).
Katja
On Sat, Feb 7, 2015 at 1:45 PM, Pierre Massat pimassat@gmail.com wrote:
Dear Katja,
Could you please tell us what buffer size you're using in Pd ? Can you
get
lower than 16 ms without dropouts with a reasonable patch with both adc
and
dac ?
Thanks in advance,
Pierre.
2015-02-07 10:39 GMT+01:00 katja katjavetter@gmail.com:
On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette msp@ucsd.edu wrote:
Also try running "pd -nosleep", which sometimes persuades kernels to schedule the process differently :)
Indeed, "pd -nosleep" does the magic. Command htop shows hat the kernel has 100% CPU time reserved on one core (fixed per session) for pd -nosleep. Pd-gui runs on one of the other cores, alternating. The audio is fine with no dropouts.
It is possible to start two instances of pd -nosleep, and get a core reserved for each. The second instance finds the alsa device busy of course, and this makes no sense in practice. Maybe the [pd~] object can profit from the multicore processor.
I've checked current draw with the setup: Raspberry Pi + USB keyboard
- USB mouse + USB audio interface (iMic) together consume ~400 mA with
only the desktop running, and ~450 mA with pd -nosleep running idle or with a CPU intensive patch. This indicates there is some frequency scaling going on after all. I'll look into that again when there's more info about the new Pi's config defaults and options.
Katja
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list