Description of the problem: when presenting a loop of a routine (comprising a fixation cross for 1.5 seconds, a movie and a sound component) the very first trial completely fails the timing: the fix cross is way to long and the sound is cut at the end. The second trial works fine but I really would like to figure out what is happening here.
First, I used frames as duration for the fixation cross, but it didn’t work (the fix cross actually stayed on for the whole time, without moving on with the movie component), so I switched to duration in seconds. However, since the timing between Movie and Sound is essential, I set the timing of both components to frames. Maybe this is important to know when looking for a solution…
I build a very simplified version of the actual experiement to test the timing that looks like this:
thank you for your reply! I shared my project with you and hope it worked Let me know if you need anything else!
Edit: When testing our experiment, we noticed that the timing between a movie and audio gets really variable from trial to trial, especially when we read the files from a csv. We actually thought that a fixation period of 1.5 seconds in the beginning of the routine is sufficient for the movie and audio to pre-load and enable an exact timing but it doesn’t seem to work out… Instead, we have lags between the movie and the audio from 0 to around 160 ms… Do you know what we can do about this?
according to my edit about the variability between trials, I also did some analysis. In the two pictures below you see the timing difference (recorded with a photosensor on the screen and a microphone right next to the loud speakers) between two trials when presenting a video and audio as described yesterday. Although the video and audio should always be the same, i.e., occur after specific number of frames after a fixed fixation period, the timing between both actually varies a lot!
This is a even bigger problem than the weird first trial and I’m really concerned that we cannot find a solution to it… We also tried the same with a movie that already contains the audio trace (because we thought it should be fixed within the movie then) but we observed the same phenomenon…
I am really grateful for your help and hope that you might find a simple explanation we can fix!
Hi @elani, many thanks for all the very helpful information. I have created a support fork in which I have: (a) upgraded to PsychoJS latest, (b) replaced the fixation cross BMP with a ShapeStim, (c) placed the fixation cross in a separate routine to avoid having movie playback start on condition, (d) set movie file input to constant instead of each frame, (e) switched the experiment to height units, (f) changed the background color to black. Could you give it try, see if it runs any better? x
First, the general timing looks pretty good so far! I just have to change the start time of the audio, since the 1.5 seconds of the fix cross are in another routine now.
However, as you can see in the first image, the audio in the first trial is again shorter than the audio in the rest of trials… The timing of the fixation cross looks stable though.
Some general questions to your changes:
Do you think it makes more sense to define the start and duration in online studies as frames or better in seconds?
Since you changed some things to load less images, is it helpful to have small file sizes and less material to upload?
Is it unnecessary to “preload” the movie and audio file during the time of the fixation cross (now the fix cross is in the separate routine)?
Looking forward to your feedback
One more thing: I am curious why you chose the setting height instead of norm?
And another “one more” : How did you update the PsychJS to the most recent? I tried it in another test experiment but it still the version 2021.1.4.
Hi @elani, thanks for the data. Frames per second will vary, but there is nothing different code-wise between the first and later trials. I wonder if specifying sound durations in seconds might give you better results in any case. Images, movies, sounds, and other assets are preloaded automatically before the dialog box can be okayed. Their size should have no effect on stimulus scheduling accuracy. I chose height units, because certain visual elements seemed distorted otherwise, x
Let me know if you need anything else!
