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.
if you are disabling sync, make sure you disable it for all contexts including pwindow / pworld contexts. Windows I know does not like multiple sync enabled contexts (or at least that used to be the case).
Also, as ever in Jitter, if you want the most stable frame rate your patch should have absolutely 0 updating UI elements in it, no flonums, no fpsgui, nothing. If you need to control your patch and maintain this stability, split your patch into 2, a GUI and an engine, and run each in a separate instance of Max passing data via udpsend/udpreceive (some OSC equivalent).
Hi, and thanks for the advice.
The UI elements for this simple patch don't seem to interfere, but you never know.
Update:
It seems to me that the problem depends heavily on the vertical refresh rates of the main monitor (A) and the secondary monitors/projectors (B).
In general, I've noticed fewer problems if the refresh rate on monitor B is the same as or higher than that of monitor A.
Monitor A 59.98 Hz and monitor B 60 Hz:
Monitor A 50 Hz and monitor B 60 Hz:
Problems seen so far
Monitor A 50 Hz and monitor B 50 Hz:
It seemed the most stable, but in the end, it gives the same problems, and not all devices can operate at 50 Hz.
Monitor A 59.98 Hz and monitor B 50 Hz:
It's hell, with sync on, I constantly lose frames. If I disable sync, jit.world shoots up to 300 fps, but the actual refresh rate calculated on the control PC tells me 40 fps.
Monitor A 59.98 Hz and monitor B 59.94 Hz:
jit.world at 60 Hz and sync on, the actual refresh rate calculated is 50Hz, to get 60 fps. I have to set jit.world to more than 100 fps for output (always with sync on).
It seems that if the frame rate of monitor B is lower than that of monitor A and I keep sync on, it creates a mess and I constantly get a lot of dropped frames.
In this case, it's better to keep sync off and use monitor B's frame rate, but it doesn't always work.
I'll do my next tests with a single monitor, so without having the patch in view.
Hi,
I ran some additional tests and it seems that the presence of UI elements does not affect my patches. They are probably not heavy enough to put significant load on the system.
With the patch from my show, I reach about 30% GPU usage and 40% CPU usage.
A few clarifications:
I normally do not use OBS; I only used it to record the output so I could show the result.
The video issue appears on the secondary monitor, while the main patch is displayed on the primary monitor.
What I found instead is the following:
the dropped frames seem to depend heavily on the vertical refresh rates of the monitors.
When the refresh rates are exactly the same, the issue behaves differently: it happens less often, but when it does, it lasts longer.
It reminds me of the beating phenomenon in physics.
Test method
I used the patch running on the master computer of my show, with several UI elements active. They are basically full-screen jit.gl.gridshapes with texture applied that scroll at the same speed using the jit.world bang to increase the position, the same principle as the first example patch I posted.
On a second computer, I analyze the HDMI video stream and calculate how many frames are dropped each second and log the data to a file, in order to analyze it and generate a graph.
Test 3
Primary monitor: 2560×1080 @ 59.98 Hz
Secondary monitor: 1920×1080 @ 60.0 Hz
fullscreen window on the secondary monitor
27,104 dropped frames in almost two hours
Test 2
Primary monitor: 1920×1080 @ 60.0 Hz (one of the available resolutions that gives exactly 60 Hz)
Secondary monitor: 1920×1080 @ 60.0 Hz
fullscreen window on the secondary monitor
NO DROPPED FRAMES IN TWO HOURS
Test 1
Primary monitor: 1920×1080 @ 60.0 Hz (one of the available resolutions that gives exactly 60 Hz)
Secondary monitor: 1920×1080 @ 60.0 Hz
not fullscreen window on the secondary monitor
31,230 dropped frames in two and a half hours
What happened around second 2000 and second 9200 is that I tried a workaround:
I opened and then closed a small empty patcher that I had prepared for this test.
At around second 3500, something happened spontaneously, without any manual interaction.
It's like the graphics engine is asleep and then suddenly resumes sync
Note that when you reach 20/25 dropped frames per second, these dropped frames are never consecutive.
After a dropped frame, there's always a correct one, so the image runs at 30/40 fps and never freezes for more than one frame.
Has anyone else experienced dropped frames related to mixed or slightly different monitor refresh rates?
Is this a known limitation of jit.window / jit.world when using multiple displays, or something that can be mitigated through specific settings or best practices?
Does this behavior match any known issues with multi-monitor setups and refresh-rate synchronization in Max?
I would be very interested to know if there are recommended workflows or configuration strategies to avoid this kind of frame loss.
Thanks for your help!