Harald, What you said makes perfect sense. However, in the original code, where the issue was initially found, the second duration call was not made until several seconds into the program which leads me to think the issue lies somewhere else. That said, I'll give it a go and see what happens. Kas, I'll give Jack2 a go tonight as well and see what the results of that are. Thanks all, -Matt

Date: Fri, 27 Apr 2012 10:00:37 +0200 From: signal.automatique@gmail.com To: chuck-users@lists.cs.princeton.edu Subject: Re: [chuck-users] LiSa looping issue

On Fri, Apr 27, 2012 at 09:41:40AM +0200, Harald wrote:

...

My guess: I think chuck needs some time to initialize and build your audio chain (in your script) etc. But you try recording beginning at the first sample. So chuck isn't ready early enough and jack misses some response from chuck. Something like 1000 ms => now at the start of the script may change that.

Yes, that seems reasonable. Another thing is that Jackd2 is far more forgiving about missing a few periods than Jackd1 is. 1 will disconnect you over missing deadlines while 2 won't. There must also be advantages to 1, or it wouldn't still be developped and available, but because of this I use 2.

Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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).

Probably, yes. Especially allocating memory is a OS task and so depends on when the OS would like to get 'round to that. Most OS's are not optimised for realtime performance there. Therefore it's not recommended to allocate memory in programms that need realtime performance.

yes, this makes me think of Matt's words: "is it possible that the low amount of RAM?". Allocating memory from RAM alone isn't such a big thing nowadays (but may be on your old laptop). *But*, if memory is low, this might make the OS swap thing out of the RAM, which is the main problem for real time performance. Swapping stops the program for some time, which may easily exceed the time for playing one buffer. Especially on an old laptop which often has slow disks. I think you (=Matt) should look at this one first...

On Fri, Apr 27, 2012 at 09:52:03AM -0400, Matt Bard wrote:

All,

...

I think you (=Matt) should look at this one first...

Agreed. I have a much newer laptop (running Windows) that I will give a test on. Your (Harald) comments made sense. Let me get back to you guys tonight after trying a few of these things. And just for clarity, I never intended to use .duration as I assumed it required more overhead (including requesting memory)... my goal was to use .clear, but when that failed, I moved on. Regardless, I'll let you guys know what I find. I really appreciate all the thoughts and help.

Check. One idea; .clear() will take as little resources as something like that could; at one simple loop it'll all fit in the CPU cache and should go through at a blazing speed... but the total time will depend on how many entries it needs to iterate over. at some point any cpu will run out of steam. Not allocating more memory than you will need will keep it to a minimum. So; if 4 seconds is enough don't allocate a minute. Maybe that was already obvious. Kas.

I forgot... Is the RT error of the kind "access violation", or what else? "access violation" often means accessing an area already freed before, and then I'd assume clear() doesn't clear the values alone, but also remove the buffer, which IMHO wouldn't make much sense.

On Sun, Apr 29, 2012 at 07:19:06PM -0400, Matt Bard wrote:

So, it appears this might be an old computer issue more than anything else. After testing some on my new laptop, it appears that all works just as expected. I also tried a very short duration (100ms or less) on my older computer and was able to get things working. That means that ChucK is behaving properly, so far as I can tell.

End good all good.

While we're on this though, is there any way to spork a function that doesn't operate on the same period in Jack? For example, is there a method to allow this to be done out of realtime through a separate thread? I'd still like to be able to use the old machine for this.

I'm not sure I understand the first question, the second sounds like a (partial?) re-phrasing of my suggestion to have parsing and compilation done in a separate thread (probably with a lower priority to the OS) than the main one which also runs the VM. If that is your question then no, all of ChucK is in a single thread, from the OS perspective. There has been talk of improving that and about other strategies to reduce the CPU load. The load is indeed quite high, and it is high for solid reasons, but not all of those reasons are likely to be there all the time so gains could be made there.

Thanks for all the help and thoughts!

You are welcome, that is what lists are for. Yours, Kas.