[PD] new raspberries

katja katjavetter at gmail.com
Sat Feb 7 15:22:49 CET 2015


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 at 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 at gmail.com>:
>>
>> On Fri, Feb 6, 2015 at 11:56 PM, Miller Puckette <msp at 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 at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>
>



More information about the Pd-list mailing list