My (Mac) application is latency sensitive, so I let the AudioServer know (via kAudioDevicePropertyIOCycleUsage) how late it can call my thread to provide output for the device.
So far, I've done this by "benchmarking" a worst-case work-load when setting up my IOProc func (see here if you're curious).
How would I do this now with potentically asymmetric cores? I would like my benchmark to be called under the same performance characteristics as under the "real output" case, but without actually having a real deadline or having to produce real output.
So far, I've done this by "benchmarking" a worst-case work-load when setting up my IOProc func (see here if you're curious).
How would I do this now with potentically asymmetric cores? I would like my benchmark to be called under the same performance characteristics as under the "real output" case, but without actually having a real deadline or having to produce real output.
Some testing on actual hardware seems to indicate that the IOProcs (which default to the workgroup of their respective device) seem to end up on the performance cores.
If I could force the scheduler to run my benchmark either on the same cores as the IOProcs will, *or* force it to the efficient cores (that way I will have increased latency but at least it wouldn't matter where the actual IOProcs are scheduled, I will always have enough leeway). But as far as I'm aware, macOS doesn't have any "core affinity" APIs.
As my benchmark is triggered in response to a UI interaction, I'd assume it runs w/ high QoS (as it's user-interactive), so currently it's probably also on the performance cores...
If I could force the scheduler to run my benchmark either on the same cores as the IOProcs will, *or* force it to the efficient cores (that way I will have increased latency but at least it wouldn't matter where the actual IOProcs are scheduled, I will always have enough leeway). But as far as I'm aware, macOS doesn't have any "core affinity" APIs.
As my benchmark is triggered in response to a UI interaction, I'd assume it runs w/ high QoS (as it's user-interactive), so currently it's probably also on the performance cores...