The compute engine completely stops when the application loses focus

[aalex]

After a while, the update rate drops to almost completely stop.

The current backend model that implements the minimum required to run generators in the backend. It runs a single thread for running generators separate from the GUI thread.

It still has some timing issues — it will become unstable when other applications are taking up a lot of CPU, and also when the app is not the "topmost" or "active" app on the operating system. Unfortunately when it does, it becomes unusable. The framerate crashes down from 30Hz to less than 1 update per 5 seconds. This might be a bug with QTimer, or this might just be a bad implementation. More investigation is required. A much more stable (but terribly energy and CPU-inefficient) solution would be busy waiting.

[simondemeule]

Some progress was made on this — part of the instability was caused by the compute engine not actually running on its own thread due to the way its timer worked — it relied on the GUI thread's event loop to function. This is now fixed in branch fix-compute-engine-crashes-and-instability as of 1eed6cd, but more work needs to be done, as the engine still stalls when losing focus, and there seems to be threading bugs still present.

[simondemeule]

I'm currently discussing this issue and #88 on a monome forum thread dedicated to audio programming.

[aalex]

As I mentioned, I suggest to avoid writing a multi-thread application, for now. It would be a lot easier. Premature optimization is the root of all evil. (See https://stackify.com/premature-optimization-evil/ )

If you want to continue to develop a multi-thread application anyhow, I've sent you a few links:

• Check dans MapMap 0.6, on avait une thread séparée pour l'OscReceiver. (maintenant, c'est du passé) https://github.com/mapmapteam/mapmap/blob/0.6/src/control/OscReceiver.cpp#L11 La thread était gérée à 100% à l'intérieur d'un objet. Pour communiquer avec le monde extérieur, on utilisait une messaging queue.
• https://github.com/mapmapteam/mapmap/blob/0.6/src/control/OscInterface.cpp#L89 - C'est simplement le Command Design Pattern.

[simondemeule]

Looks like this issue is specific to macOS, and is caused by a power management feature of the operating system — timer coalescing or "App Nap" as Apple calls it. I've confirmed that this is indeed the problem, as turning off that feature system-wide using sudo sysctl -w kern.timer.coalescing_enabled=0 prevents the compute engine from stalling. I found some information that addresses this specifically in the context of Qt timers (our exact problem!). It seems really straightforward but I'm having a bit of a hard time making it work — @aalex do you know how to make these magical .mm files do their thing? Also related: this stackoverflow thread.

[simondemeule]

Another relevant thread.