<br><br><div class="gmail_quote">2010/4/4 Dan Wilcox <span dir="ltr"><<a href="mailto:danomatika@gmail.com">danomatika@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div><div></div><div class="h5"><br><div><div>On Apr 3, 2010, at 2:39 AM, tim vets wrote:</div><br><blockquote type="cite">Hi all,<div>I have a rather heavy patch which causes DIO errors when I switch~ on several subpatches.</div>
<div>I'm running pd + Jack on a rt kernel (ubuntu-studio Hardy),... Jack shows little or no Xruns.</div><div>Now I wanted to try and optimize the patch by using [pd~].</div>
<div>The way I understood it is that [pd~] will start a subprocess and it will (automatically ?) divide the audio computation load over multiple processors.</div><div>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.</div>
<div>Any advice very welcome!</div>
</blockquote><br></div></div></div><div>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.</div>
<br></div></blockquote><div>Hi Dan,</div><div><br></div><div>I've been trying lots of things, mostly using ubuntu.</div><div>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.</div>
<div>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.</div><div>It is a quad-core machine, but I heard that when you run pd on it, it will only use one processor. </div>
<div>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...</div><div>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...</div>
<div>Is it even possible to run pd -rt on a non-realtime kernel ?</div><div>At the same time, I discovered some inefficiencies in my patch, which I should adapt.</div><div>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).</div>
<div>Are there more efficient ways to do this kind of tracking ?</div><div>gr,</div><div>Tim</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div>
<span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="border-collapse:separate;color:rgb(0, 0, 0);font-family:Helvetica;font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="word-wrap:break-word">
<div>--------</div><div>Dan Wilcox</div><div><a href="http://danomatika.com" target="_blank">danomatika.com</a></div><div><a href="http://robotcowboy.com" target="_blank">robotcowboy.com</a></div><div><br></div></div></span><br>
</span><br>
</div>
<br></div></blockquote></div><br>