3 ms·
Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio work
by duped 1y ago
Developers aren't (yet) abusing audio workgroups for all their thread pools to get pcore scheduling and higher priority. So it would imply that if an audio workgroup is issuing commands to the GPU there should be some kind of timeout to the GPU downclocking based on the last time a workgroup sent data to it.
GPU audio is extremely niche these days, but with the company mentioned in TFA releasing their SDK recently it may become more popular. Although I don't buy it because if you're doing thing on GPU you're saying you don't care about latency, so bump your i/o buffer sizes.
- krackers 1y agoI'm not too familiar with audio workgroups but since the early days XNU had low-level APIs to set pthreads as pseudo-realtime
- xmodem 1y agoThis will definitely get you to run with a higher priority than the user's time machine backup, but it's not guaranteed to get your code onto a p-core if the machine is on battery and your app doesn't have focus.
- Archit3ch 1y ago> if you're doing thing on GPU you're saying you don't care about latency This does not follow. Evidently it is possible to have low-latency audio processing on the GPU today (per the SDK).