# Mworks sound issue

**URL:** <https://mworks.discourse.group/t/mworks-sound-issue/888>\
**Category:** Support\
**Created:** [April 24, 2023, 7:07pm UTC](https://mworks.discourse.group/t/mworks-sound-issue/888 "2023-04-24T19:07:36Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\
**Post date:** [April 25, 2023, 7:48pm UTC](https://mworks.discourse.group/t/mworks-sound-issue/888/4 "2023-04-25T19:48:06Z")

</div>

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](https://github.com/mworks/mworks-issues/issues/445) 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](https://mworks.discourse.group/t/audio-improvements/835) (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:

```auto
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

---

_[View the full topic](https://mworks.discourse.group/t/mworks-sound-issue/888)._