Audirvana not using Audio Workgroups yet?
Understanding Audio Workgroups
Meet Audio Workgroups
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:
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.