Need some help with pD / tables / IR reverb


#1

Anybody here has some experience with tabread4~ pD ?

I’ve made a very simple 4-track sample player using tabread4~ and it gets all glitchy (and pD often become slow and unresponsive).
I’m running pD on the latest Raspbian on a Rpi 3. The patch is a relatively simple one: I have 8 tables (for 4 stereo samples) and read those using a phasor~ object, adding some MIDI control over pitch, volume and some lowpass filtering (using bob~).
When checking CPU load inside pD it tells me I’m at 77%, but the system graph only says 25%. The load does not seem to change when removing channels, though one channel alone (hence 2 tables) seems to play ok.
I wonder if this is this normal or maybe if it’s my patch that is buggy?


#2

Since that might help… if anybody wants to see the pD file, you can download it here:
https://cp.sync.com/dl/bdcbe8520#s69qtk49-hy7ir6xq-pjtafpt7-vfh7mnur

It’s supposed to be used with a MIDI controller, and volumes are all set to zero to start with, so it’s normal that you don’t hear any sound.

Interstingly also the first loop payer does not play when the patch loads, I have to send it a “reset” to make it work every time.


#3

I solved it somehow.
There were a couple of things choking up the patch, one was that the samples were too long, the other was that I had some objects/abstraction taking up too much CPU time (eg. unsig~ and the VU meters).
It still does not run on the raspberry, but I’ll have to see if the problem does not lie elsewhere.


#4

After lots of testing it seems like the Rpi might just not have enough juice to handle long samples and it seems like it can totally not handle partconv~

Can anybody maybe test this for me?
It’s a very simple IR-based reverb patch. On my system it glitches like hell. But I wonder if it’s my system that is the fault.

you can download it here, it’s also Pisound App compatible.
https://cp.sync.com/dl/8ff595b30#qehdtmr8-pij6u2mk-ynakz55d-da5mbmny


#5

Seems to run fine on my RPi 3B+, no glitches :slight_smile: And the patch worked right out of the box, awesome!

I had cases where patches glitch occasionally, and this command improves things a lot:

echo performance | sudo tee /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

I’m considering including this to be called by default, before starting Pure Data in https://github.com/BlokasLabs/pisound/blob/master/scripts/common/start_puredata.sh#L36


#6

thanks a lot!
I did find out that adding [bob~] after the reverb does create the glitches, also [bob~] doesn’t like getting float numbers in its cutoff inlet, so adding a [int] in line also improves things.
So basically if the patch only includes the [partconv~] part without anything else, it runs fine, as soon as I add something else it starts to glitch.
I did try your suggested tweak with the original patch (which included bob~) and it didn’t improve things. My guess is that it’s just too much for the 3B, but might work on the 3B+ since it’s got a little bit more juice.
Still thanks a lot for the help!


#7

bare in mind that PD is single threaded (more precisely it only has one dsp thread) , i.e. its on one core. so it doesn’t take much to overload dsp on a rPI.
(top allows you to show per core load too… Im guessing your 25% is the one line summary)

changing the governor usually makes a quite difference, perhaps you already had it set some how?
(you can cat the same file, to see if it set to performance or ondemand)

the pi3b+ adds about 15% more cpu, so it might be its on a threshold.

unfortunately audio glitches are a bit ‘digital’ (on/off) … doesnt matter how late you are on your dsp processing… you get a glitch, also this is for every buffer, so any ‘extra’ load can take you occasionally into extra glitch - so you could need just 1% more, and it might work

to fix, could also try with a larger audio buffer, this is always worth doing - as it allows you to see how far you are off, and also if the glitch is a underrun, or ‘a feature’ of the patch code.

another option, is to consider using pd~ which basically launches another pd (and consequently gives you another dsp thread on a different core), it adds a little bit of latency. (I believe it’ll be one audio buffer of latency, but not tested yet)

my plans is to use this with Orac, by putting each orac chain (optionally) on different cores, where the platform supports it - this would allow it to scale better.
(not got around to it yet, since Organelle/Bela are single core, so really its only the rPI… but ‘design’ is in my head, including dealing with issues of a different process space etc )

obviously given the rPI pretty limited resources, moving from one core to multi core opens up a considerable amount of dsp. (id say, 2-3x, as you still need a bit left over for the running of the OS, externals IO threads etc, which are currently running on those cores)


#8

Thanks a lot @thetechnobear for the detailed info and tips! Much appreciated! I’ll try that as soon as I have a moment!


#9

I can also confirm that the patch is working nicely for me right from the app! 3b+. Just wanted to say that bc I know we were having some similar issues @kurodama


#10

@miker2049 thanks a lot for confirming!
In the meantime I managed to get the patch to work somehow. If I remove the [bob~] object, it does sound ok. It just makes some horrible glitchy noises when changing the IR sample, i.e. when swapping the contents of the table (and hence resizing it), but I guess that’s normal.
I could probably solve that by adding a temporary mute.

I did also try out pd~ but right now I can’t figure out how that works exactly when Pd runs headlessly (-nogui). On the mac when you open a patch that contains a [pd~] object the application will prompt you asking if you want to allow the additional process to be started, but not sure anything like that happens when you run Pd as -nogui.


#11

i have a reverb patch that uses IR --it’s built on top of plugin and uses the tap-reverb ladspa
it currently has 65 room sounds…let me know if that is something that helps


#12

I’d love to give it a go, if you fancy sharing it. Though the main reason I want IR to work in pd is to be able to use my own impulse responses.


#13

You can replace the IRs with your own of course


#14

sounds good!

If you have a patch you want to share, that would be really cool. If not, no big deal either, I’ll look into plugin~ and install the TAP plugins.


#15


this one has 63 reverb rooms but like i said you need LADSPA installed on your system and the plugins
but this makes use of the plugin~ loader for a nice reverb room


#16

Cool thanks a lot! Been really swamped lately, so I haven’t had time to test this, but will certainly do as soon as I finish some stuff here…