Add a description of the expectation of request_callback timing

[baconpaul]

Without making a requirement, indicate the intent of the timing.

[abique]

Maybe add a note saying that a realtime audio engine can steal all the CPU time if the audio computation is overloaded, and there is nothing the host can do about it.

[baconpaul]

OK changed it to this

   // Request the host to schedule a call to plugin->on_main_thread(plugin) on the main thread.
    // This callback should be called as soon as practicable, usually in the host application's next
    // available main thread time slice. Typically callbacks occur at least in the 10s-to-50s-of-milliseconds
    // or 30-120hz timeslice range. Plugins should not make assumptions about the exactness of timing for
    // a main thread callback but hosts should endeavour to be prompt. However in high load situations
    // the host may starve the gui/main thread in favor of audio processing, leading to substantially
    // longer latencies for the callback than the indicative times given here.
    // [thread-safe]

[abique]

maybe:
Typically callbacks occur within at 33ms (~30Hz).

Maybe just giving an idea of the worst case is enough.

[baconpaul]

OK pushed

[abique]

It is not directly the host that will starve the GUI thread but simply the kernel scheduler that won't allocate resource to it.
Some plugins also setup a realtime thread pool, which can as well starve the GUI.

[baconpaul]

It is not directly the host that will starve the GUI thread but simply the kernel scheduler that won't allocate resource to it. Some plugins also setup a realtime thread pool, which can as well starve the GUI.

I'd argue on modern architectures you can usually avoid that in a well written host, but yeah I changed it from host to environment to make the blame a bit more amorphous

[abique]

It is not directly the host that will starve the GUI thread but simply the kernel scheduler that won't allocate resource to it. Some plugins also setup a realtime thread pool, which can as well starve the GUI.

I'd argue on modern architectures you can usually avoid that in a well written host, but yeah I changed it from host to environment to make the blame a bit more amorphous

How would you avoid it?

[baconpaul]

It is not directly the host that will starve the GUI thread but simply the kernel scheduler that won't allocate resource to it. Some plugins also setup a realtime thread pool, which can as well starve the GUI.

I'd argue on modern architectures you can usually avoid that in a well written host, but yeah I changed it from host to environment to make the blame a bit more amorphous

How would you avoid it?

Pin your ui thread to an efficiency core and pin your audio thread to the powered cores for instance would help a lot.

[abique]

Pin your ui thread to an efficiency core and pin your audio thread to the powered cores for instance would help a lot.

My computer doesn't have efficiency cores :-)
Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

But yes, if you reserve some dedicated resources for the GUI, you can achieve it.

[baconpaul]

Ha yeah

I was just reflecting on how well bitwig and logic do this in Mac honestly when I wrote that comment

but that’s just chatter here not what I put in the pr. The pr just points out it might be worse

[abique]

In Bitwig we effectively don't use the efficiency cores on macOS M1 because they rarely meet the deadline.

We should try again to use them and see if the scheduler is able to do a good job. In theory it could because there's a workgroup (deadline sched) from coreaudio that you can join, and the kernel knows that all the threads that belongs to this group have to meet the audio interface's deadline.

So it isn't a specific resource allocation for the GUI that we did but more a workaround.

[baconpaul]

gotcha.

well logic does according to my cpu meter! and it works great!

[abique]

Thank you 👍