Super slow performance and video freezing in an eye-tracking experiment

heliocuve

Hi All,

I am working on an eye-tracking experiment, where I want to display videos in open-sesame (3.2.5) and collect gaze data through Tobii tx300. I am using the pygaze plugin in OS. I seem to get things working, but the experiment seems to be running pretty slow, and the video display sometimes freezes in the last frame before moving on. I am not sure what is causing this lagging, as the task is not supposed to be super computationally demanding, it is just a passive view task. I have tried switching the backends, the psychopy backend doesn't show the video. And while the pygame and experiment backends work, it freezes often, which is not ideal, as I am left wondering if the gaze data will be recorded correctly. The experiment runs fine in a simple dummy mode.

Any ideas of solutions are appreciated.
Thank you,
Helio

sebastiaan

Hi Helio,

If I understand correctly, the video plays back smoothly in dummy mode, but things become laggy if you enable the Tobii. Is that right?

If so, that suggests that some part of the Tobii software slows things down. This could be either the Tobii SDK itself, or the implementation of PyGaze. Looking at the source code, PyGaze indeed continuously collects and logs gaze data from the Tobii, which I imagine can slow things down.

@Edwin Any thoughts?

Cheers!
Sebastiaan

Edwin

Hi all,

Sounds like an accurate diagnosis, @sebastiaan! Tobii did their own implementation, so you might be able to ask the Devs about it on GitHub, @heliocuve.

You can open an issue there, and tag them. (Or open the issue, and I will tag them.)

Cheers,
Edwin

heliocuve

Thank you @sebastiaan and @Edwin for your comments. I will loop in the devs.

Cheers!
Helio

heliocuve

Hi, again @sebastiaan and @Edwin.

So, I found out that if I put a blank sketchpad between the video stimuli and the pygaze_log, it seems to solve the lag in the video display, and now the only lag is caused by the pygaze_log as @sebastiaan suggested. Is there a way to specify exactly which variables are to be logged in the pygaze_log file, so that I can potentially reduce the amount of stuff being written to the gaze file, and hopefully this reduces the lag during the pygaze_log period.

Another question, is it a problem if I move the pygaze_stop_recording to before the pygaze_log? I realized that the gaze data is still being recorded during the lag period where py_gaze logs the variables. So stopping the tracker earlier would perhaps make the file a little bit cleaner? if I have to log a lot of variables?

Thank you again!
Cheers!
Helio

sebastiaan

Is there a way to specify exactly which variables are to be logged in the pygaze_log file, so that I can potentially reduce the amount of stuff being written to the gaze file, and hopefully this reduces the lag during the pygaze_log period.

Yes, you can disable the 'Automatically log all variables' option and then explicitly indicate what you want to log, like so:

var response [response]
var condition [condition]

Another question, is it a problem if I move the pygaze_stop_recording to before the pygaze_log? I realized that the gaze data is still being recorded during the lag period where py_gaze logs the variables. So stopping the tracker earlier would perhaps make the file a little bit cleaner? if I have to log a lot of variables?

I'm not sure if stopping the recording will also prevent log messages from being written. For the EyeLink it would, but for the Tobii it may be different. Why don't you give it a shot?

Cheers!
Sebastiaan

Edwin

To give a more specific answer to your second question:

Before calling the stop_recording function, data is streamed and logged (in a local buffer). When you call it, the buffer is synced to disk (to the log file). By calling the log function, you're writing directly* to the log file (as opposed to adding your message to e.g. a Queue), and thus it doesn't interfere with or is dependent on the active streaming of samples.

TL;DR You're fine logging outside of start_recording to stop_recording.

* Small print: It is not actually directly, as it's still writing to a local buffer (which will be wiped during e.g. a crash or loss of power). Once you call stop_recording or close, the data is synced to disk (and thus will persist beyond crash power outage). Fortunately, if OpenSesame crashes, the close function is called automatically, and thus all data should be saved anyways.

heliocuve

thanks loads guys! I got this part working smoothly now.

cheers!
Helio