Intermittent Frame Drops with jit.world (Max 8 / Max 9) on any computer
I'd like to report a problem I've been having lately on dozens of different desktop/laptop with Windows 10/11 and laptop Mac Intel, with Max 8.6.5 and Max 9.1.1.
I initially thought it was due to the complexity of my patches or the size of the textures, but below is a very simple patch that shows the same error: a simple rectangle that scrolls from left to right once a second, the jit.world bang calculates its position, sync on, 60 fps.
The issue appears after a short time (usually within the first minute), lasts for about 5–15 seconds, then performance returns to normal. After some time, the problem repeats.
Note that on Windows jit.fpsgui always reports a stable 60 fps, and I haven't found a way to check these dropped frames from within Max.
The only way I've found to objectively check for dropped frames is to use an HDMI to USB-C video capture card on another computer and calculate when there are duplicate frames.
Is this a known issue related to jit.world, internal scheduling, or the rendering loop?
Could this be related to:
Garbage collection / memory management?
Internal OpenGL context resets?
OS-level GPU scheduling or power management?
Are there recommended flags, attributes, or diagnostics to better understand these periodic drops?
Thanks
Rossano
Here's a video montage comparing two videos.
The top one is what comes out of the monitor and therefore what you see in reality.
The bottom one is the video recorded internally by OBS; there are very few dropped frames.
You'll hear a beep every time a frame is dropped. The video is at 60 fps.
Just to be sure I understand correctly, you have one patch running and its output is recorded both through your HDMI output for the upper part of the video where we observe frame drops (we can easily see the white bar jittering when bips occur), and at the same time using OBS for the lower part, right?
Is the OBS recording done through screen capture or Spout/Syphon?
You should probably submit a ticket and provide the link to this thread to be sure the staff sees this.
That's correct.
On PC1, I ran the Max patch with the window in fullscreen on an external HDMI 16:9 monitor at 1280x800 at 60Hz (even the main monitor is at 60Hz, if I set it to 75Hz it gets messy).
At the same time on PC1, I recorded with OBS using "Window Capture" as the source in automatic mode.
On PC2, I recorded the HDMI video stream; what I recorded is what I saw live, there are no dropped frames due to the PC2 being too slow.
I then analyzed the video from the HDMI, highlighting the dropped frames with a beep.
The video I uploaded is a video montage where I aligned the start of the two videos and added the audio track.
I've already opened a support ticket and am awaiting a response.
I'm curious to know if this happens to you too.
On the Mac platform, at least on Intel, the difference is that the dropped frames are reflected in the jit.fpsgui, which drops to almost 40 fps and then rises back up to 60 fps.
Silicon Mac here. The displayed FPS is super steady, although I do see some slight stutter from time to time, which can also be seen in a screen capture. That's very subtle though:
Looking at the video frame by frame in VLC, there are a few dropped frames, like it goes from 30 to 32 but stays at 32 for two frames and then keep moving. Now I'm wondering if the recording itself can miss frames, as if the frequency at which Max-generated images could not be perfectly in sync with the recorded frames, even though both keep a steady 60 images per second overall...
Thanks for the test.
I think the problem is much more noticeable if the window is on a secondary screen.
I have a setup with six computers and six side-by-side video projectors, and the problem is very annoying because it appears and disappears randomly.
I'm trying to disable sync and increase the frame rate, keeping a separate qmetro at 60 fps for calculations, but it doesn't seem to solve the problem.