[chuck-users] dur frame?
ssalazar at CS.Princeton.EDU
Tue Feb 17 05:32:26 EST 2009
Im not quite sure what you are specifically finding odd/disturbing
here--feel free to elaborate further if maybe I missed something. HID
events are received from the operating system in a thread separate
from the VM thread; upon receiving an event, the HID thread signals
the VM that the event corresponding to that HID event should be
broadcasted. The VM checks for activated events at least once every
sample. So the events could really show up at any point in ChucKian
time; whether its exactly in bufsize intervals depends on how fast the
HID events are coming in and how much CPU time ChucK takes to
calculate one full buffer of samples -- less CPU time per buffer will
lead to greater likelihood of Hid events on buffer boundaries.
I agree that a buffer size constant is pretty useful; I think this
will actually probably be implemented soon since its pretty easy to do.
On Feb 16, 2009, at 8:46 PM, Kassen wrote:
> To get back to this for a moment;
> I was working with this same setup again and so again interested in
> interpolating data over the span of one block.
> At some point in a debugging process I had ChucK print the duration
> (in samples) since the last Hid message at the moment a message
> arrived. Mostly this resulted in numbers that were either my buffer
> size or a integer multiple of it but sometimes I got numbers that were
> slightly off (by a few samples, sometimes as much as a dozen or more)
> and would (apparently) be compensated for in the next frame. This was
> on Linux using a RT Kernel, BTW.
> To me this is a bit odd and slightly disturbing, could anybody with
> more insight in the internal workings of the engine shed some light on
> what I might be seeing there?
> In other news, I'm now convinced that having the duration of the
> block/frame size as a constant (like "samp") in the language would be
> a useful thing that we should seriously consider. Clearly it's not
> something that everybody needs all the time but there are occasions
> where it is very useful and it would increase the potential
> portability of code that uses realtime input as the framesize does
> affect how we can look at incoming data from within the language.
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
More information about the chuck-users