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! Thanks, Tim
hi tim,
just to be sure, do you use the -rt flag when starting pd? also, try to run everything (jack, pd) in root (just to see if the glitches is the cause of a limitation).
pat
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.
Dan Wilcox danomatika.com robotcowboy.com
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
Dan Wilcox danomatika.com robotcowboy.com
-
Dan Wilcox -
patrick -
tim vets