TouchQueue: how to empty queue to not overflow numSlots?

Hi Mario,


Overall, I am at the moment very happy with the touchscreen functionality, thank you again for getting this into psychtoolbox. However, there are two issues at the moment I am struggling with. The first one is a minor thing: whenever I initialize several touchscreens, the process hangs at some point and I need to touch any screen to continue. This seems to be related to what is happening with TouchQueueStart. Interestingly, it does not matter what screen I am touching, whether it is the current device that needs to be started, a previously started one or one that still is waiting for its start. I have for testing at the moment three screens, and it hangs with the second screen when I need to touch any screen once, and then it continues and all screens work fine.


The second issue is a bigger problem for me. When I create the TouchQueue there is the numSlots parameter (default set to 100000). The documentation says "Number of input slots for storing touch events. You must empty the queue frequently enough, so no more than 'numSlots' events collect in the queue, or the queue will stop storing new events and drop information." I noticed, that matlab freezes after some number of trials, and that this freezing depends on the numSlots parameter, i.e. if I set it to a smaller value, the freezing happens earlier. I was assuming that TouchEventFlush would empty the queue, but is does not seem to have an effect. I tried to increases this parameter, but as I expected it relates to pre-allocating memory, and large values lead to Matlab exiting with a segmentation fault.


Releasing the touchqueue and re-creating it does not work for me right now because of the issue with the need to touch at least one touchscreen in the process. I can not do this on a trial-by-trial basis.


thank you,

wolf

Hi Mario,

Sorry, it took a while to run all tests. I wrote a test script (attached) that does not use matlab's oop. The freezing does occur in Matlab (2018a) as well as Octave (4.2.2), even when only a single touch device is attached. The value set for numSlots determines how many touches can be read on the screen before freezing. It seems to be something like numSlots-4. If I query TouchEventAvail after reading out touch events, it seems that navail is 0.

It seems that neither, TouchEventGet or TouchEventFlush clear the buffer.

If I set a very low value for numSlots (10) it practically freezes immediately after starting.

There are no error messages, matlab freezes, keeping one CPU at 100 % usage.


wolf


---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner.de@...> wrote :

On Thu, Mar 7, 2019 at 7:31 PM wolf.zinke@... [PSYCHTOOLBOX]
<PSYCHTOOLBOX@yahoogroups.com> wrote:
> Hi Mario,
>
> Overall, I am at the moment very happy with the touchscreen functionality, thank you again for getting this into psychtoolbox. However, there are two issues at the moment I am struggling with. The first one is a minor thing: whenever I initialize several touchscreens, the process hangs at some point and I need to touch any screen to continue. This seems to be related to what is happening with TouchQueueStart. Interestingly, it does not matter what screen I am touching, whether it is the current device that needs to be started, a previously started one or one that still is waiting for its start. I have for testing at the moment three screens, and it hangs with the second screen when I need to touch any screen once, and then it continues and all screens work fine.
>

Weird. Why does this only show up now and not 5 months ago? Can't
think of a way this could happen. Only happens on multi-X-Screen? Or
also on single X-Screen with multiple touchscreens? Or single X-Screen
with single touchscreen? I need you to spot the exact
location/function in the code where that happens. Which
Matlab/Linux/X-Server version etc. is this? Does it also happen under
Octave? Would be easier to attach a debugger to Octave.

I don't have any touchscreen(s) to debug this, which makes debugging
much more painful, also essentially no time to look into this atm.

>
> The second issue is a bigger problem for me. When I create the TouchQueue there is the numSlots parameter (default set to 100000). The documentation says "Number of input slots for storing touch events. You must empty the queue frequently enough, so no more than 'numSlots' events collect in the queue, or the queue will stop storing new events and drop information." I noticed, that matlab freezes after some number of trials, and that this freezing depends on the numSlots parameter, i.e. if I set it to a smaller value, the freezing happens earlier. I was assuming that TouchEventFlush would empty the queue, but is does not seem to have an effect. I tried to increases this parameter, but as I expected it relates to pre-allocating memory, and large values lead to Matlab exiting with a segmentation fault.
>

TouchEventFlush() should empty the queue, i can't see anything wrong
with the current code in PTB beta. So you say navail =
TouchEventAvail(deviceIndex) doesn't return zero events after a
nflushed = TouchEventFlush(deviceIndex)? What is the value of
nflushed?

Apart from that, each TouchEventGet() removes one item from the queue,
so should free up space as well.

What version of Matlab is this? How does it behave on Octave?
-mario

>
> Releasing the touchqueue and re-creating it does not work for me right now because of the issue with the need to touch at least one touchscreen in the process. I can not do this on a trial-by-trial basis.
>
>
> thank you,
>
> wolf
On Wed, Mar 27, 2019 at 10:38 PM wolf.zinke@... [PSYCHTOOLBOX]
<PSYCHTOOLBOX@yahoogroups.com> wrote:
> Hi Mario,
>
> Sorry, it took a while to run all tests. I wrote a test script (attached) that does not use matlab's oop. The freezing does occur in Matlab (2018a) as well as Octave (4.2.2), even when only a single touch device is attached. The value set for numSlots determines how many touches can be read on the screen before freezing. It seems to be something like numSlots-4. If I query TouchEventAvail after reading out touch events, it seems that navail is 0.
>
> It seems that neither, TouchEventGet or TouchEventFlush clear the buffer.

If navail = TouchEventAvail reads navail == 0 after reading out touch
events via TouchEventGet, then obviously it is clearing the queues
properly. If TouchEventFlush does the same then everything is working
as intended.

I just tested this with regular KbQueues on Octave 4.2.2, as i don't
have access to any touch screens, and as far as i can tell, clearing
the queues works just fine. That script if yours is a total chaos of
TouchXXX calls, as you should use them, and low-level PsychHID()
calls, which you should absolutely not use in the way you do. I don't
know if they are right or not, but wouldn't be surprised if you made
mistakes in that chaos. E.g., you call PsychHID('KbQueueCreate', ...,
8, ...) when there is no valid flag setting 8 at all. The setting got
silently ignored, but may lead to future bugs at pretty much any
future PTB update. The whole thing will also be entirely prone to
breakage or non-portability as soon as i'd make changes to touch input
code.

Maybe you should try with our touch input demo script
MultiTouchMinimalDemo.m, only modifying the numSlots parameter to
TouchQueueCreate to something small, and see if the problem still
happens. Also run KbQueueDemo, which tests queue flushing for keyboard
queues. Also make sure you don't have some stray copies of PsychHID or
old code in your path, doing unexpected things. Also make sure your
touch screens don't somehow add new touch events without you touching
anything, e.g., due to some touch hardware malfunction.

I can't reproduce these problems with KbQueues on Linux Ubuntu
18.04-LTS + its standard Octave 4.2.2 at all, and the touch queue
management code is shared with KbQueues, so i assume that the mistake
is somewhere in your chaotic script or your setup. If not, there isn't
anything i could do without getting some touchscreen donated to
reproduce and test this myself.

-mario

>
> If I set a very low value for numSlots (10) it practically freezes immediately after starting.
>
> There are no error messages, matlab freezes, keeping one CPU at 100 % usage.
>
>
> wolf
>
>
> ---In PSYCHTOOLBOX@yahoogroups.com, <mario.kleiner.de@...> wrote :
>
> On Thu, Mar 7, 2019 at 7:31 PM wolf.zinke@... [PSYCHTOOLBOX]
> <PSYCHTOOLBOX@yahoogroups.com> wrote:
>
> > Hi Mario,
> >
> > Overall, I am at the moment very happy with the touchscreen functionality, thank you again for getting this into psychtoolbox. However, there are two issues at the moment I am struggling with. The first one is a minor thing: whenever I initialize several touchscreens, the process hangs at some point and I need to touch any screen to continue. This seems to be related to what is happening with TouchQueueStart. Interestingly, it does not matter what screen I am touching, whether it is the current device that needs to be started, a previously started one or one that still is waiting for its start. I have for testing at the moment three screens, and it hangs with the second screen when I need to touch any screen once, and then it continues and all screens work fine.
> >
>
> Weird. Why does this only show up now and not 5 months ago? Can't
> think of a way this could happen. Only happens on multi-X-Screen? Or
> also on single X-Screen with multiple touchscreens? Or single X-Screen
> with single touchscreen? I need you to spot the exact
> location/function in the code where that happens. Which
> Matlab/Linux/X-Server version etc. is this? Does it also happen under
> Octave? Would be easier to attach a debugger to Octave.
>
> I don't have any touchscreen(s) to debug this, which makes debugging
> much more painful, also essentially no time to look into this atm.
>
> >
> > The second issue is a bigger problem for me. When I create the TouchQueue there is the numSlots parameter (default set to 100000). The documentation says "Number of input slots for storing touch events. You must empty the queue frequently enough, so no more than 'numSlots' events collect in the queue, or the queue will stop storing new events and drop information." I noticed, that matlab freezes after some number of trials, and that this freezing depends on the numSlots parameter, i.e. if I set it to a smaller value, the freezing happens earlier. I was assuming that TouchEventFlush would empty the queue, but is does not seem to have an effect. I tried to increases this parameter, but as I expected it relates to pre-allocating memory, and large values lead to Matlab exiting with a segmentation fault.
> >
>
> TouchEventFlush() should empty the queue, i can't see anything wrong
> with the current code in PTB beta. So you say navail =
> TouchEventAvail(deviceIndex) doesn't return zero events after a
> nflushed = TouchEventFlush(deviceIndex)? What is the value of
> nflushed?
>
> Apart from that, each TouchEventGet() removes one item from the queue,
> so should free up space as well.
>
> What version of Matlab is this? How does it behave on Octave?
> -mario
>
> >
> > Releasing the touchqueue and re-creating it does not work for me right now because of the issue with the need to touch at least one touchscreen in the process. I can not do this on a trial-by-trial basis.
> >
> >
> > thank you,
> >
> > wolf
>
>
On Mon, Apr 1, 2019 at 11:42 PM wolf.zinke@... [PSYCHTOOLBOX] <PSYCHTOOLBOX@yahoogroups.com> wrote:

Hi


I added the navail = TouchEventAvail(dev) line and write the number out. It is indeed counting down before it freezes (see below).


Yep, that output looks exactly as expected with properly working queue management. With the current, just updated, PTB beta, Matlab shouldn't crash anymore, but the queue should simply silently overflow if it doesn't get emptied quick enough.

So as far as i'm concerned, PTB either works as expected, or the problem can't be resolved without me having convenient access to proper touchscreen hw.

Yes, I can increase the value for numSlots again, finding a value that does not lead to a segmentation fault. However, my reasoning to reduce the number was that I actually get touch events in pretty fast cycles, since, similar to my first chaotic example test script, I run an ongoing while loop and check for events in every iteration, i.e. within a couple of milliseconds. Therefore I did not see the need to pre-allocate a huge buffer.


Right in principle, but you'd have to make sure the buffer is always big enough that it could cope with a multi-second pause if your script would be paused/stalled on something. And the default queue size of 100000 slots doesn't consume more than 62 MB even with 5 touchscreens active, a tiny amount of memory on modern multi-GB RAM machines.

I can't see however, how the current code in PTB Beta could possibly freeze, even with a tiny queue. The worst that should happen would be loss of some touch events, e.g., from a finger motion trajectory.

If a freeze indeed happens and this is not a bug in your script, but something that also happens with our scripts, then i'm out of ideas and could only debug this with a suitable touchscreen. Donations welcome.

-mario

wolf


1 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
2 touches still in queue
1 touches still in queue
0 touches still in queue
2 touches still in queue
1 touches still in queue
0 touches still in queue
3 touches still in queue
3 touches still in queue
2 touches still in queue
1 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
0 touches still in queue
1 touches still in queue
0 touches still in queue
0 touches still in queue