Audirvana not using Audio Workgroups yet?
Understanding Audio Workgroups
Meet Audio Workgroups
This is probably why music playback is unstable, right?
Hi @taka,
We took a look at it when it was announced, but we don’t need to use it.
“The diagram below shows how Core Audio runs an I/O thread in the audio server as part of the audio device’s workgroup. The thread wakes up at regular intervals and calls its associated client app to retrieve its audio output. When the client finishes rendering its audio, the system writes it to the output hardware, and the I/O thread sleeps. If a client takes too long to produce audio, the thread misses its deadline, which results in an audio overload and an interruption in audio playback. The I/O thread is the primary thread of an audio device workgroup, and it informs the kernel of the beginning and end of each work cycle.”
→ Audirvāna does not work this way, we thus don’t need this:
1 Like
Thank you for your reply.
The following part of the “Meet Audio Workgroups” video:
1:19
Up until now, the main input into the performance controller’s decision-making has been observations about the running applications and daemons: how many threads are they using and how much work they are doing? Now, because of the time-critical nature of audio, we’ve given it a new input into the performance controller: the new workgroup APIs.
Is Audirvana doing something equivalent to that “new input”?
I’m concerned that the performance controller may not be able to be properly controlled on Apple Silicon Macs.