[PD] new raspberries

Pierre Massat pimassat at gmail.com
Sun Feb 8 21:20:40 CET 2015


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 at 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 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20150208/ed17cd04/attachment.html>


More information about the Pd-list mailing list