Holiday notice: Cycling '74 will be closed on Dec 25th, 26th, and Jan 1st. Manual authorization, support cases, and manual order processing will be delayed.
Entire core (100%) CPU usage when overdrive turned on (Mac)
Jun 03 2018 | 8:13 pm
Hi,
I'm having this weird issue where when I turn overdrive on, even with no patches open (or having ever been open since max started), Max jumps to 100% CPU usage or above (1 entireCPU core used) and stays there until overdrive is turned off.
If overdrive is on at Max startup, there does not seem to be a problem. It only happens when overdrive has been turned off and then back on again, or was off at startup and you are turning it on.
(unfortunately i need to turn overdrive off temporarily for something in one of my main patches or else Max crashes…)
If I turn overdrive on via the menubar it ALWAYS jumps to 100% CPU.
If I turn overdrive on via the Audio Status window, the Prefs or an adstatus object in a patch, it jumps to 100% CPU about 20% of the time. Its unpredictable. In the patch using a "delay 0" vs a "deferlow" after the toggle object doesn’t change behavior (makes sense i guess because when you’re turning it on, there is only 1 thread…).
I haven't found any scheduler settings in prefs that affect this behavior.
I tried removing all my Max packages and deleting ~/Library/Application Support/Cycling74/, which appeared to reset all the Max prefs, etc. No change.
Also tried moving entire ~/Documents/Max 7 folder. No change.
Audio ON/OFF does not seem to affect the issue, and it still happens if audio driver is set to "None".
When this problem happens, Max slows down and timing gets sloppy. The computer works really hard on patches that it normally has no problem with, and sometimes audio glitches.
Anyone else see this? Thoughts?
Max 7.3.5, MacOS 10.13.4, MacBookPro11,3 (Retina, 15-inch, Mid 2014)
Thanks,
Arvid
- Jun 03 2018 | 11:45 pmwhat happens when you deselect the audio driver for the IO you use?
- Jun 04 2018 | 12:05 amThanks, but no audio driver or input/output device setting seems to make a difference. The runaway CPU usage seems to be the scheduler thread, not the audio thread, which is reporting between 0% and 1%.I also just tried it without any external displays attached (so embedded GPU in use) - no change.Its also very strange that it behaves differently depending on whether Overdrive is switched on from the menu or a patcher, which leads me to believe it has something to do with which thread switches it on - some sort of race condition/timing mishap that always happens from the menu activation, but only sometimes from other methods of activating Overdrive that are probably triggered in the Max main thread. I wonder if maybe menu commands are executed in a different thread than main or scheduler in Max?Next step is to try on a new test user i guess, then on a new OS install. Yuck what a waste of time :(I've been noticing this issue on and off for about a year (definitely in OS X 10.12 too), but figured it was caused by something weird i was doing in my patch. I never noticed it could happen even when no patch had been loaded since max startup.
- Jun 04 2018 | 10:46 ami think we can be sure that the file menu isnt in the main thread (and so is the mouse?) :)but if something like this happens without custom patches open and without audio, i am really at my wit´s end.anything third party added which loads at startup?
- Jun 04 2018 | 7:09 pmplease file a bug report by clicking "Report a problem" in the Support menu above.
