[PD] buffer and performance woes on OSX

Jesse Mejia jmejia at anestheticaudio.com
Tue Jun 21 22:51:47 CEST 2016


Hi list,

I’m having some performance problems - clicks/dropouts when I feed my patch too much note concurrency by way of midi input into some [clone]d karplus strong abstractions among other things - but only when I’m concurrently sending midi out.

I’m finding that the audio settings menu hangs PD depending on what buffer size I choose. I’m only able to choose 64 or 128. 

Typically I would increase buffer size to compensate - but the only other buffer setting that doesn’t hang pd is 128 and it actually gives me even more dropouts. I’ve tried playing around with block~ but couldn’t really get that helping either.

'defeat real-time scheduling' seems to help things somewhat. and running -rt didn’t seem to do anything either way.
-nogui also didn’t help

I’m using a fairly unimpressive 2-core mac mini.. and I do have about 1/2 of my DSP running in a pd~ instance
so maybe I just need to run this on a more powerful machine.

I’m sending a fair amount of midi data via ctlout to some micro controllers. Basically the more note-ins my patch receives - the more ctlout data it sends. Removing that part of the patch makes the dsp blocking clicks go away - but it seems like the midi out shouldn’t be interfering with audio so much. Is there a way to make PD prioritize the audio over the midi output? It would be great if I could wrap the midi output stuff in a lower priority abstraction somehow… I don’t think pd~ helps me there because there isn’t actually any DSP in the midi output abstraction - just control data...

OSX 10.11.1 (el capitan)
Pd 0.47.1
Motu 24AO (though it was experiencing audio blocking and also lock ups on the audio settings panel w/ the internal interface as well)

Any tips?

-Jesse


More information about the Pd-list mailing list