I have been working directly with Karl on this problem and I think we are now at a manageable state. What really made the difference was using Latencymon to track issues (the first of which was ACPI.sys, but it wasn’t the only one) and determining which CPU they were prominent in. Once we did that, we realized that the first 4 CPUs were the ones most likely to support these processes with latency hits.
The resolution was to use a batch file using the “affinity” command to start Gig Performer 4 so that Gig Performer processes would only run in CPUs 4-7 (the processors are numbered from 0-7 in a 4 core device). The value to use for setting affinity is a hex value (based on a binary byte). Ex. A value of FF (or 1111 1111 in binary) would utilize all processors. A value of FE (or 1111 1110 in binary) would utilize all processors but the last one, which is CPU 0. (** Note that for affinity settings the CPU #s run from 7-0, not 0-7). I used hex F0 (1111 0000) in order to avoid CPUs 0-3. A “1” in any of the processor positions of the byte will enable the associated processor. You can use any binary to hex calculator to get the hex value once you decide which CPUs to avoid if you are not already familiar with hex conversions.
See: [Binary to Hex Converter]
After doing this, audio issues appear to be almost non-existent, even when pushing the machine with extra stuff, like Windows Defender, networking, Spotify, etc.
Latencymon still shows some issues (although much less often) in processors 0-3 when pushing the machine with extra stuff. However audio issues appear to be very rare and of a minimal nature if they occur at all.
Here is the text of the batch file I used:
@echo off
c:
cd \Program Files\Gig Performer 4
start /AFFINITY F0 Gigperformer4.exe
I hope this helps someone else as much as it did us.