(Painful)Journey to Timing Test in Apple Silicon (M1, M2, M3) Mac

To long story short,
-It seems that the issue is mostly OS related, not from hardware.
-The last macOS with working proper timing is Monterey (in 7th January, 2025. Timestamp matters, since Apple can patch someday).

All the tests are done with coder demo script ‘timeByFramesEx.py’.
In macOS Sonoma, miserable frame drop, and binomal distribution of frame & flip intervals.
Then multi-boot tested with AsahiUbuntu, Since AsahiLinux(Fedora based) requres a lot of package compile to install latest PsychoPy. without docker.


The difference is amazing. Now looks like usual 60Hz Display. However, the AsahiUbuntu seems a bit unstable. random framedrop happens and the number of dropped frames are hugely vary. below is the worst result.

Since many postings reported that frame issue arised after Ventura upgrade, I downgraded M1 macmini to Monterey.
Now, still not very satisfying, but proper distribution.

I will re-run the test with proper 120Hz setting of EIZO FG2421 monitor when USB-C to dP cable arrived.

Roll-back to Monterey is not easy. It requires DFU restore, if you are in Sonoma or later.

2 Likes

Below is the Monterey result. Due to New user restriction.

2 Likes

We also find that with Sonoma (MacOS 14) and Sequoia with 2 different computers there is a timing problem for frame flips, evident below in the output from Demos->timing->timeByFrames.py
You can see that while the mode is the correct value is 16.6, at least half the times between win.flips are shorter or longer than that, and shorter should be impossible if the waitBlanking (which is set to True) were working. Has this been reported to Apple, or how can we make progress on this?

2 Likes

Interesting. Apple may have very specific (internal) guide for frame sync using metal…
Psychtoolbox team seems to find something since they run free beta test.
For me, still no idea… It may due to issue in python frame-controller in the libraries Psychopy built on. (i.e. pyglet, pygame…)

1 Like

When you say “psychtoolbox team seems to find something since they run free beta test.”, do you mean that they have a beta version of Psychtoolbox which doesn’t have this problem? Or do you mean something else by “beta test”? Thanks!

@According to December 13, 2024 update, they resolved it ‘partially’.

Highlights:
Initial “Beta” Apple Silicon support for running Psychtoolbox on macOS for Apple Silicon Macs. Psychtoolbox can now be used with native Octave and Matlab for Apple Silicon ARM Macs, ie. machines with Apple M1, M2, M3, M4, … SoC’s. Most basic functionality should work reasonably well, and substantially better than when using older Psychtoolbox versions via Matlab for IntelMacs, which had various severe limitations which would make them painful to use and deeply hazardous for any real data collection! This versions Apple Silicon support was tested by myself on a Apple MacBookPro early 2023 with 16 inch Liquid Retina XDR display and Apple M2 Pro SoC under macOS 14.5 Sonoma with 64-Bit native Octave 9.2 from HomeBrew, and with Matlab R2024a and with Matlab R2024b. It was also more lightly tested by others on a similar 16 inch MacBookPro late 2023 with M3 Pro SoC under the macOS 15.2 Sequoia beta under Matlab R2024b, and a MacBookAir 2020 with M1 SoC, and a Mac Studio 2023 M2 Ultra and MacBookAir M3 13 inch early 2024, the latter two with macOS 15.2 beta and Matlab R2024b. Thanks to our volunteer testers.

While surely some bugs or limitations still exist, this should be a first good release for basic use and evaluation.

Known limitations are lack of frame-sequential stereo support in stereo modes 1 and 11, Screen Async flips, ie. subfunctions ‘AsyncFlipBegin’, ‘AsyncFlipEnd’ and ‘AsyncFlipCheckEnd’ are unsupported. Certain glitches in frame presentation timing are still observed under certain conditions at least on macOS 14, e.g., stalls / short freezes after the stimulus image was static for a while, e.g, observable with MouseTraceDemo if not moving the mouse for a while. These may also trigger printing of some warning messages into the Matlab or Octave Window about “…Failed to retrieve … stimulus onset timestamp! Timed out.”. It is not yet clear if these issues are still present on macOS 15 Sequoia as well, testing to be done. These remaining timing glitches are almost certainly due to Apple macOS operating system bugs, which will either need proper fixing by Apple, or need invention of new creative workarounds on our side, if that is needed and possible.

Apples “ProMotion” display mode on some builtin Retina displays, e.g., of the MacBookPro models, and variable refresh rate modes in general, are not supported and will cause more erratic behaviour. Make sure to switch to a fixed refresh rate mode in display settings instead on such machines.

Movie playback, movie writing and video capture works well with GStreamer 1.24.10, but due to what seem to be shortcomings or bugs of current GStreamer releases, video recording on Apple Silicon only works for video, not when also trying to record audio - otherwise hangs will occur. On Intel Macs, video recording does not work at all with GStreamer 1.24.10, but does for both video and audio with GStreamer 1.22, however with the downside that playback of some movies fails. So both GStreamer 1.22 and 1.24 have some limitations, pick the variant with limitations you can better live with, until GStreamer is properly fixed in some future GStreamer version.

You should probably not yet use this release for real data collection if highest reliability of visual stimulus presentation timing is required. Use for less demanding scenarios may be fine, but tread carefully with this early release!

1 Like