Yes, the OS also has its own event loop, which might be more responsible for that kind of timing, as it isn't running at a fixed rate and keyboard is probably a lower priority than mouse or network events.
Martin Ico wrote: > > Many thanks for the explanation! What seems weird, however, is how divergent > time delta between repeats is. On Windows it is always around 30ms (at least > on my hardware) whereas on Linux it goes between 0, including 1.4ms and up to > 50+. Even when accounting for jitter between two events I cannot imagine that > they oscillate that much (unless my flavor of kernel/hardware treats keypress > timing like a dirt :-). > > Best wishes, > > Ico > > [email protected] wrote: > >> >>It probably happens when you get two keydowns in the space of one Pd event >>loop. The second is output at the same time. The same thing happens with >>[metro] banging serial data into [comport] or [midiout]. The metro rate is >>quantized to the event loop rate, so individual bangs are irregularly spaced >>but the mean time over many bangs is perfect. The only way to get perfect >>timing is to use signals, messages are always handled after the sound has >>been computed. >>So if you don't like it you could slow down your keyboard repeat rate to >>slower than Pd, or use a microphone to detect the keypresses ;) >> >>Martin >> >> >> >> >>Ico wrote: >> >>> It all started when I noticed that my threaded version of coll object >>> tended to freeze Pd at apparently random points. As it turns out, I was >>> testing its robustness simply by passing a key into a read/write message >>> and holding the key down to generate a large number of requests per >>> second and the [key] object at times seemed to spit out (while >>> autorepeat of the pressed key was taking place) two outputs at the same >>> time which in turn crashed Pd as threaded coll object did not handle >>> this gracefully. I've since fixed the coll object but the key behavior >>> baffles me. >>> >>> The double redundant output is apparent in both rt and non-rt Pd (on >>> Ubuntu 9.10 using rt kernel on the MSI Wind atom netbook) and below is >>> the simplest patch to invoke this. >>> >>> Basically, I am measuring the aforesaid time delta between broadcast >>> strokes using timer object and printing it out to console. >>> >>> #N canvas 549 345 383 297 10; >>> #X obj 162 83 key; >>> #X obj 162 107 sel 32; >>> #X text 208 108 space; >>> #X obj 162 145 timer; >>> #X obj 162 182 print; >>> #X connect 0 0 1 0; >>> #X connect 1 0 3 1; >>> #X connect 1 0 3 0; >>> #X connect 3 0 4 0; >>> >>> So, while certainly the fact that threaded version of coll wasn't >>> handling gracefully multiple redundant requests at the same time was a >>> bug (which I am hoping has been fixed now), I am wondering whether the >>> aforesaid [key] behavior might be a bug as it seems to me that >>> keystrokes of the same key, even if the key is autorepeating should >>> never have a time delta of zero. Naturally, one can always put a >>> speedlim after the [key] object but that might result in a truncated >>> output of fast typing. >>> >>> I would greatly appreciate it if others can test this to see if they are >>> getting the same results. >>> >>> FWIW, allowing this kind of key behavior in more complex patches did >>> result in the pd<->gui communication tearing with the stderr reporting >>> several truncated messages before crashing. Due to their complexity and >>> unpredictability of a point where tearing would occur I am not sure >>> where the problem might be stemming from but it is undoubtedly at least >>> in part instigated by double redundant output from the key object >>> possibly in conjunction with objects that may have not provided graceful >>> handling of such requests. >>> >>> NB: I only tested the same patch on Win platform and there it does not >>> exhibit this problem. >>> >>> Any thoughts would be most appreciated. >>> >>> Best wishes, >>> >>> Ico >>> >>> >>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> http://lists.puredata.info/listinfo/pd-dev >> > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
