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