How to measure kAudioDevicePropertyIOCycleUsage with asymmetric cores?

Question

Created Jun ’20

Replies 3

Boosts 0

Participants 2

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.

Answered by maven in 617913022

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...

Boost

Answer 1

maven OP

Jul ’20

Accepted Answer

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...

0

Answer 2

Media Engineer OP

Apple

Jul ’20

I am not really following what exactly you are trying to do. But here are some comments on your post:

IOProcs will run on the HAL real-time thread that is associated with an audio workgroup in the OS, meaning that it will have performance impact in the system, such always running threads on performance cores and higher power consumption. If you want to run other threads concurrently with the same priority and performance/power properties as the HAL thread, please use the new audio workgroup APIs.

0

Answer 3

maven OP

Jul ’20

I'll try to explain again: My app is forwarding audio from one (virtual) input device to (real) output device. This process is driven by the IOProc of the output device. As I want to incur as little latency as possible (i.e. use the most up-to-date data from the input device), I want my IOProc to be scheduled as late as possible while still hitting the deadline (see the documentation for kAudioDevicePropertyIOCycleUsage the header docs are more helpful, the web documentation seems useless).

But I do have a bit of work to do to the data before it's ready, so I need to figure out what I can set kAudioDevicePropertyIOCycleUsage to and still hit the deadline (from the documentation you get scheduled the entire cycle of the audio duration with the default IOCycleUsage). So far, I've been benchmarking the workload how long my audio fiddling needs (on some synthetic input data) before starting the IOProc, and then multiplied that by a safety factor and adjusted kAudioDevicePropertyIOCycleUsage accordingly.

There are no other threads involved in this work (so the AudioWorkGroup APIs shouldn't be needed), but I'm wondering how to best do the estimation of the IOCycleUsage now that differently speedy cores are in play. Either I need to benchmark on the performance cores (and then the IOProc always should run on the performance cores, or I need a safety factor of how much slower the efficiency cores are), or I need to force the benchmarking onto the efficiency cores (that way I'll never be late, but I might leave some latency on the table).

Does that make some sense?

0