2010/4/4 Dan Wilcox <danomatika@gmail.com>

On Apr 3, 2010, at 2:39 AM, tim vets wrote:

Hi all,
I have a rather heavy patch which causes DIO errors when I switch~ on several subpatches.
I'm running pd + Jack on a rt kernel (ubuntu-studio Hardy),... Jack shows little or no Xruns.
Now I wanted to try and optimize the patch by using [pd~].
The way I understood it is that [pd~] will start a subprocess and it will (automatically ?) divide the audio computation load over multiple processors.
However, I get the impression that by using [pd~] I get the same (or even worse) results as with my regular "abstraction / [switch~]" approach; DIO error crackles.
Any advice very welcome!

Have you had clicks before?  In my experience running Linux, I have had much fewer dio errors (basically none) running pd -rt on a *non* realtime kernel.  I use the basic Ubuntu kernel with realtime privileges enabled, no running pd as root.  I also do not use jack but alsa directly, which seems more stable.

Hi Dan,

I've been trying lots of things, mostly using ubuntu.
I didn't use jack before, but at some point it seemed I could get lower latency with it, so I started using it a few months ago.
I'm rebuilding my setup around a heavy and bulky desktop now, because my laptop is too old, and I could not get really playable latency.
It is a quad-core machine, but I heard that when you run pd on it, it will only use one processor. 
I was hoping that I would be able to 'spread out' my patch over several processors using pd~, but so far I haven't had any luck...
In any case, using the realtime kernel now, I'm pretty sure I get less clicks at lower latency settings. But I havent really compared recently...
Is it even possible to run pd -rt on a non-realtime kernel ?
At the same time, I discovered some inefficiencies in my patch, which I should adapt.
One of those is in a subpatch where I use 6 bonk~ objects, and another subpatch that uses 6 sigmund~'s. (to track my guitar strings).
Are there more efficient ways to do this kind of tracking ?
gr,
Tim