I’ve finally started making some patches using pd with pisound and here are my impressions:
for simple patches I/O latency is very low and all works fine.
However
using 16 oscillators at once is impossible even with high delays and block size, I can manage 32 with onboard sound or hifyberry.
I would say that pisound cuts half of processing power of Raspi. mhhh, disappointing…
Hi, what are the audio settings you are using, including sampling rate, buffer sizes, etc? Pisound itself is not participating in data processing or buffering, all of that is done by the CPU on Raspberry Pi.
would also be interesting to know with Raspberry model you are using…
Also make sure that you’re using one of the Pisound’s natively supported sampling rates, one of 48kHz, 96kHz and 192kHz. Otherwise, based on your system configuration, resampling may occur, reducing the performance of audio software.
Raspi 3 here, I’ll make some tests at 96Khz and see, will report back this evening.
thanks
48kHz might be the best option in terms of latency and performance for complex audio processing.
I once had the sampling frequency erroneously set to 44.1K and indeed that did make the performance quite a bit more laggy at higher loads. I guess the CPU does have to resample the audio before forwarding it to the audio hardware in these cases.
Does Pd take a hit from using pisound? I would think it would offset the speed and the performance would be BETTER than before. What does that pd patch look like? 16 metros on those Oscs? 
j/k
pp
I now seem to have a similar issue.
I am running a simple patch that plays some samples with yabread4~ and it definitely have something around 40ms latency. Might be due to Pd’s tabread function, or it might be freeverb~ (which I’m adding in the signal chain) that does that, so it needs more testing. I’ll keep you posted.
After some testing I think I know what the problem is: first of all Pd does add a bit of latency when using tabread4~, but it’s very little (maybe 4-5ms), but I can’t get Pd to read the settings I add when using in the normal GUI mode as user “pi”, so when running it with the button the delay was set to the default 25ms as opposed to the 5ms I had set in the GUI. I fixed that for now adding:
-audiobuf 5
to the single-click button script which seems to work fine with my patches.
I’m looking into that though, because I also need it to get the search paths right.
update: gave up Pd reading the prefs when launched from the button, it just won’t work, the solution is to add all the stuff you need in the script and be done with it. The only downside is that there is a bit of a double effort when adding more externals.
I disagree
freeverb~ is a KNOWN CPU HOG
Did you compile freeverb~ from source?
There are literally dozens of other reverbs MUCH more efficient to use that sound better than freeverb.
Not to mention using plugin~ and loading http://tap-plugins.sourceforge.net/ladspa/reverb.html
and you get oh a MUCH nicer reverb and it’s convolution based so you can pick different rooms
Thanks for the heads up on plugin~
Though I reducing the latency to 5ms worked fine even with freeverb in the patch. I didn’t compile it from source, I just took the version from the repo. Though I did move to another convolution-based reverb which is available as a Pd external since. What was the name again? Can’t remember, atm but can look it up if you want. I do love convolution reverbs and have lots of IRs I have made over the years.
here is one that hold 63 separate IR rooms --it wioll be a part of the Blokas Pd Patch repo i am working on right now
you need the plugin~ external and you need LADSPA for it to work but it give you 63 separate room sounds. This one was made for organelle and is being updated this weekend for use headless on/with the pisound.
enjoy
cool thanks a lot, will give it a try!