On Mac OS ARM there are E-cores and P-cores (Efficient and Performance).
From “Activity Monitor” you can observe the general load on the individual cores. Ardour is the only application that is executed on jackd (jackd -R -d netone). When the audio starts to crackle I found a correlation: the numerous threads of Ardour switch from the P-cores to the E-cores.
Error details:
JackEngine::XRun: client = ardour was not finished, state = Running
JackAudioDriver::ProcessGraphAsyncMaster: process error
I switched from Ardour 8.0 to 8.12 but the problem persists and it seems that it is not possible to set the cpu affinity as you do with windows os.
macOS manages thread placement primarily through the kernel scheduler, and explicit thread-to-processor binding is not supported
I appreciate advice on what to do, regards.
Using Thread Affinity API:
API:
macOS provides an affinity API that allows developers to hint the kernel about thread scheduling based on affinity sets.
pthread:
You can use the pthread_mach_thread_np(pthreadId) function to obtain a Mach thread ID for a given thread, which can then be used with thread_policy_set to influence its affinity.
Limitations:
This API is not as fine-grained as Windows’ CPU affinity settings and relies on hints rather than strict binding.
Considering Jack would cause the process thread via callback, this seems like it would be a feature request for Jack instead of Ardour. Especially as I don’t think this problem exists on the coreaudio backend. Speaking of which, why aren’t you using coreaudio on Mac instead?
When you use Ardour’s CoreAudio backend (not JACK), Ardour not only uses Apple’s MACH timeshare API to request realtime priority (using pthread_mach_thread_np as you mentioned), but also puts the process threads in the audio workgroup (to prefer performance CPUs when necessary).
When using JACK, Ardour plays no role in any of this (JACK provides the callback and sets up process threads and thread priorities). Nothing we can do about.
Thanks for the explanation from which I understand that the problem depends on “jackd -R -d netone” rather than Ardour which is affected by it.
Unfortunately I can’t use CoreAudio (and jackd doesn’t have an interface to CoreAudio anymore, it only runs in userspace and with Rosetta emulation) because the processing is very heavy (352800Hz) and I’m using 3 Mac mini M2 synchronized with a linux server with a PCIe Digigram AES/EBU multichannel card (176400Hz exporting the timer to snd_aloop for synchronous dxd processing on the ethernet).
I’m also using a 6000 mtu on the ethernet network (jack_netsource -m 6000), I’ll try to redefine the dsp load redistribution and use a jack period larger than 6.5ms to allow a large time margin for all tasks to complete on all 3 Mac minis. I’ll do the necessary optimizations later once everything is working perfectly. (tcpdump will help me to do a timing diagnosis on the ethernet network.)