2012/4/27 Matt Bard
the second duration call was not made until several seconds into the program which leads me to think the issue lies somewhere else.
ok, I think I missed that point... The second call makes the difference, so my theory doesn't apply here. A duration call will probably throw away the buffer and allocate a new one. Also, clear() will loop throug the buffer and set all values to 0. It looks like your laptop needs too much time for this. Generally you have to balance two things: - buffer size in jack which directly determines the latency - time which all those operations need which fill the buffer while another is playing In an ideal world the buffer size should not matter. The time to calculate a buffer depends linearly on the buffer size (= number of values to be calculated). But, the handling of those buffers will have a nearly constant overhead (creating a buffer, moving it around from ugen to ugen etc.). So small buffers will result in more overhead. Another problem is when something suddenly needs some more time, like setting the duration in your case. If the timing is tight (so playing time of a buffer minus calculation time of a buffer is small), this additional time will give you an xrun, because the buffer isn't ready when jack needs it. If you increase the buffer size in jack the timing will have more room for these additional actions. But this is at the cost of a bigger latency. Btw., if the pure calculation needs more time than playing the buffer, then you won't solve this with a bigger buffer size. You would get xruns all the time (which doesn't happen in your case).