Hi Alina,
The task first runs as desired. Sound keeps playing after hitting pause or stop if resuming the task. However, if I close the experiment and reload it, sound no longer plays. No error message. Only a full restart of the computer seems to help.
Thanks for reporting this. It’s definitely a bug – actually, more like an interaction of several bugs, old and new. I’m working on untangling them.
In the meantime, you can work around it by closing and re-opening the MWServer application before loading a new experiment. There’s no need to restart your Mac.
This sometimes leads to an inability to connect to localhost, which I solve with more restarts.
That’s an unrelated problem that I see sometimes, too: Immediately after a restart, MWClient won’t connect to MWServer, and the problem persists until I restart again. It’s been hard to investigate because it doesn’t happen frequently.
There are also delays when displaying the stimuli with the nextFrame requirement.
Yes, that’s a result of something I mentioned in this discussion (under “Start time”). In short, the next frame time is too close to the time at which you invoke play_sound. As I said previously, I’m not sure what the right solution is.
One thing worth noting is that next_frame_time() gives the predicted time at which the next frame will start to appear on the display. With most displays, the frame will be drawn, top to bottom, over the full refresh period of the display (e.g. ~17ms for a 60Hz display). This means that it might actually make sense to start sound playback at the middle or end of the refresh period. For example:
play_sound (
sound = sound_stimuli[sound_stim_index]
// Start playback in the middle of the draw cycle for the
// next frame
start_time = next_frame_time() + 0.5e6 / refresh_rate()
)
This also might give the sound enough extra time to avoid the “sound is starting later than requested” warning.
Alternatively, you could just omit start_time and let the sound start playing as soon as it can. As I said in the other discussion, the actual start time shouldn’t be more than 10-20ms after the play_sound action. If that uncertainty is unacceptable, then we’ll have to think about other ways to get audio and video in sync. Probably this will involve calling play_sound several frames in advance and then ensuring that stimuli don’t appear on screen until the desired time.
Cheers,
Chris