2009/8/14 Hans Aberg

There seems to be a timing problem with <<< ... >>> in ChucK. So take all that away in all time critical positions, and see if the problem goes away. And report back here, if it does.

I think the main issue is that printing isn't done by the VM itself and that printing to the screen is expensive, CPU-wise. This can have some quite far-reaching effects. I'm not sure it's still like that but a long time ago I noted that when I'd print something, then immediately afterwards quit the shred the printed message sometimes wouldn't show. This could be fixed by advancing a bit of time after the print command. Of course advancing time may not always be possible in all conditions without causing timing issues to the overall program. Yours, Kas.

On 14 Aug 2009, at 14:23, Kassen wrote:

...

There seems to be a timing problem with <<< ... >>> in ChucK. So take all that away in all time critical positions, and see if the problem goes away. And report back here, if it does.

I think the main issue is that printing isn't done by the VM itself and that printing to the screen is expensive, CPU-wise.

I have been searching the sources a bit, and it seems that the engine has to do a lot of interpretation to get the stuff printed out. Searching for "<<<" gives chuck.y: | L_HACK expression R_HACK { $$ = new_exp_from_hack( $2, EM_lineNum ); } Then "new_exp_from_hack" is defined in chuck_absyn.cpp: a_Exp new_exp_from_hack( a_Exp exp, int pos ) { a_Exp a = (a_Exp)checked_malloc( sizeof( struct a_Exp_ ) ); a->s_type = ae_exp_primary; a->s_meta = ae_meta_value; a->primary.s_type = ae_primary_hack; a->primary.exp = exp; a->primary.linepos = pos; a->linepos = pos; a->primary.self = a; return a; } Then ae_primary_hack is used in chuck_emit.cpp, where the case calls emit_engine_emit_exp(), which seems to be a function that unwinds the closure that the expression points to. Continue the chase if you so like - it would be fun to know where it is printed. So it seems a lot of stuff has to be done in real-time interpreting. Probably has nothing to do with buffering to the computer, which are so fast nowadays. It would explain other timing problems, like with audio-files. Hans

On 14 Aug 2009, at 18:02, Bozelos Dimitris wrote:

It will be a pain in the ass to remove all the <<< ... >>> I have in my code but I guess I have to... Yes, I'll report back if I see any difference.

It is not so slow if you have an editor that can handle regexp (regular expression) search-and-replace. Enable it, and search for something like: <<<.*>>> You might also try redirecting the output. Try chuck ... > chuck.out And then in another window tail -f chuck.out This writes the output to a file name 'chuck.out', which may have less buffering problems than a console. Then the 'tail' statement creates another process that reads the output as it is written to this file, so it cannot affect the 'chuck' process. Alternatively, if you do not need the output, you might use chuck ... > /dev/null It would be interesting to know if some of these two last options help. Hans

[I nearly missed this one, because the chuck list has this idiotic reply-to field.] There are more than one source of delay problems - yours is better explained by Kassen and others. Hans On 2 Sep 2009, at 02:08, Bozelos Dimitris wrote:

Hi Hans,

at last I don't thing the reason (or at least the main reason) I was getting the xruns was the <<< ... >>> printing on the terminal. I tried removing them from the code but didn't help much, what helped most was increasing the buffer size at jack. So it is probably my soundcard that is not really good.

Thanks for the help anyway.

Dimitris