If this template helps then use it. If not then just delete and start from scratch.
OS (e.g. Win10): Win11 PsychoPy version (e.g. 2024.2.4 Py 3.8): 2026.1.3 Standard Standalone Installation? (y/n) If not then what?: y URL of experiment: can share in pilot mode upon request Do you want it to also run locally? (y/n) n
What are you trying to achieve?:
I have noticed in a first task involving mic recording that I have around 100 ms between the first frame and the second frame (my screen frame rate is 60Hz), my pilot data showed this delay can reach up to 200ms for some participants. Then on the next frames the delay is around 16ms as I could expect. The task consist to show an image with a syllable the participant must read. I originally thought the mic was adding extra-delays but it seems it is not the case when I switched to a keyboard response the 100ms delay was still present. I tested in another tas where participants must press a corresponding key to the one prompted on the screen (no mic at all) and I realized that there is still a decent delay between the first two frames (about 60 ms here, see below) on the first trials and subsequent ones (35 - 60 ms) before getting back to 16-17ms delay corresponding to my screen rate. I do not understand this delay and if I can have control on it. In situation where it reaches 100ms and more it seems a bit problematic regarding what I am measuring.
n = 1; t=0.001s
n = 2; t=0.065s
n = 3; t=0.078s
n = 4; t=0.095s
n = 5; t=0.111s
n = 6; t=0.128s
n = 7; t=0.144s
n = 8; t=0.161s
n = 9; t=0.178s
n = 10; t=0.195s
n = 11; t=0.211s
n = 12; t=0.228s
n = 13; t=0.245s
n = 14; t=0.261s
n = 15; t=0.278s
I could not really find related threads, but I am not sure this is an issue already discussed and that I did not use the right keywords.
What happens if you don’t start any component at trial onset aka onset = 0 but a little later? I use the trial onset time as part of the inter trial interval.
I tried and set in the builder a 200 ms delay before showing the stimulus. Below are a few timestamps with the corresponding frame number. There is still a 100 ms gap but this time after the 200 ms (202 → 302 from frame 14 to 15). So it seems something related to the displaying the stimulus, but I am not sure if I can have control on that. The number 16 is abnormally short (7ms).
n=11 VAD t=0.165
n=12 VAD t=0.181
n=13 VAD t=0.198 n=14 VAD t=0.215
n=15 VAD t=0.324
n=16 VAD t=0.331
n=17 VAD t=0.347
n=18 VAD t=0.364
I tried that by setting a separate component before the stimulus component with the same image displayed but with opacity set at 0 (transparent image). The issue remained.
I tried by setting this transparent image in the same routine for a short time before displaying the same image with opacity set at 1. The issue remained.
At some point I accidently tested the two images with opacity set at 0 and there was no more the timing issue… However, the images were transparents.
That first frame lag is pretty typical in PsychoPy - usually GPU initialization or some runtime warmup kicking in. The question for your measurements is whether you’re timestamping from when you actually flip the frame (which would be after that first spike) or from when you tell the routine to start. If you’re using something like `frame.getTime()` at flip time, you should be fine. If you’re measuring from the routine onset, that’s where the error creeps in. Does that match what you’re doing?
I used t = timeoutClock.getTime(); for timestapping. This is provided by default when using the builder. I just ran console.log(((("frame count:" + frame_count.toString()) + " | time = ") + t.toString())); in a code component in the each frame tab, so I guess this is corresponding to the first scenario you described.