Audio Dropouts (All Notes)

[Karl]

I reached out to Gig Performer support and they advised me to post my inquiry here. Thanks in advance for your attention to this rather lengthy post. Any insight would be extremely appreciated.

My gear:
Laptop: Dell XPS 15 9560
Interface: Behringer XR18 (Latest Driver)
VSTs in Use:

• Garriton CFX Piano (Light version) - VST
• UAD Waterfall B3 - VST3
• Halion Sonic - VST3
• Arturia Mini V3, VOX Continental, Wurli V2 - VST3
  Symptoms:

1. Notes dropout (suspect CPU jump to 100% each time but not sure)
2. Note dropout can occur during long held chord
3. Notes do not return until re-keyed
4. Problem not related to velocity
5. Problem not related to controller (multiple controllers tested)
6. Controller is connected via MIDI to the XR18 (not USB).

• I have followed many of the steps in the Gig Performer PC Configuration guide to optimize the system.
• Sleep mode is disabled
• Power Management settings are all at “Performance”
• Hyperthreading is disabled
• All PC drivers are current.
• I am using the current Behringer ASIO driver for the XR18
• The XR18 is being used as a MIDI interface as well as audio interface.
• I tried setting the affiinity for Gig Performer to omit CPU 0 which may have caused the problem to happen less often, but not completely eliminate it.
• Gig Performer is set to 44.1kHz at 512 samples (also tested at 256 with no difference)

•   LatencyMon indicates a problem that I don’t know how to fix.
  

•   CPU Throttling has been disabled in BIOS
  

LatencyMon report follows:

---

CONCLUSION

---

Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One or more DPC routines that belong to a driver running in your system appear to be executing for too long. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:03:37 (h:mm:ss) on all processors.

---

SYSTEM INFORMATION

---

Computer name: STUDIO-LAPTOP
OS version: Windows 10, 10.0, version 2009, build: 19045 (x64)
Hardware: XPS 15 9560, Dell Inc.
BIOS: 1.24.0
CPU: GenuineIntel Intel(R) Core™ i7-7700HQ CPU @ 2.80GHz
Logical processors: 8
Processor groups: 1
Processor group size: 8
RAM: 32619 MB total

---

CPU SPEED

---

Reported CPU speed (WMI): 2808 MHz
Reported CPU speed (registry): 2808 MHz

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

---

MEASURED INTERRUPT TO USER PROCESS LATENCIES

---

The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 575.20
Average measured interrupt to process latency (µs): 5.310089

Highest measured interrupt to DPC latency (µs): 572.0
Average measured interrupt to DPC latency (µs): 2.241226

---

REPORTED ISRs

---

Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 111.204416
Driver with highest ISR routine execution time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Highest reported total ISR routine time (%): 0.007956
Driver with highest ISR total time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation

Total time spent in ISRs (%) 0.014244

ISR count (execution time <250 µs): 177418
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-1000 µs): 0
ISR count (execution time 1000-2000 µs): 0
ISR count (execution time 2000-4000 µs): 0
ISR count (execution time >=4000 µs): 0

---

REPORTED DPCs

---

DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 2675.297365
Driver with highest DPC routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Highest reported total DPC routine time (%): 0.480511
Driver with highest DPC total execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation

Total time spent in DPCs (%) 0.560729

DPC count (execution time <250 µs): 450992
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 748
DPC count (execution time 1000-2000 µs): 2
DPC count (execution time 2000-4000 µs): 1
DPC count (execution time >=4000 µs): 0

---

REPORTED HARD PAGEFAULTS

---

Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.

NOTE: some processes were hit by hard pagefaults. If these were programs producing audio, they are likely to interrupt the audio stream resulting in dropouts, clicks and pops. Check the Processes tab to see which programs were hit.

Process with highest pagefault count: ua connect.exe

Total number of hard pagefaults 627
Hard pagefault count of hardest hit process: 345
Number of processes hit: 18

---

PER CPU DATA

---

CPU 0 Interrupt cycle time (s): 13.229785
CPU 0 ISR highest execution time (µs): 111.204416
CPU 0 ISR total execution time (s): 0.213453
CPU 0 ISR count: 173379
CPU 0 DPC highest execution time (µs): 2675.297365
CPU 0 DPC total execution time (s): 9.005176
CPU 0 DPC count: 393912

---

CPU 1 Interrupt cycle time (s): 2.564102
CPU 1 ISR highest execution time (µs): 103.744302
CPU 1 ISR total execution time (s): 0.033837
CPU 1 ISR count: 4039
CPU 1 DPC highest execution time (µs): 567.939103
CPU 1 DPC total execution time (s): 0.368147
CPU 1 DPC count: 15747

---

CPU 2 Interrupt cycle time (s): 1.684552
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 1100.545228
CPU 2 DPC total execution time (s): 0.243535
CPU 2 DPC count: 14201

---

CPU 3 Interrupt cycle time (s): 0.967627
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 223.638889
CPU 3 DPC total execution time (s): 0.025468
CPU 3 DPC count: 6590

---

CPU 4 Interrupt cycle time (s): 1.061115
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 223.404558
CPU 4 DPC total execution time (s): 0.037513
CPU 4 DPC count: 10314

---

CPU 5 Interrupt cycle time (s): 0.955093
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 295.008547
CPU 5 DPC total execution time (s): 0.016650
CPU 5 DPC count: 3330

---

CPU 6 Interrupt cycle time (s): 1.088467
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 221.439103
CPU 6 DPC total execution time (s): 0.024286
CPU 6 DPC count: 5022

---

CPU 7 Interrupt cycle time (s): 0.991880
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 220.867877
CPU 7 DPC total execution time (s): 0.014205
CPU 7 DPC count: 2627

---

[npudar]

Ouch. ACPI.SYS is a notorious one…
You can find many threads on the Internet about it, causing troubles, even in our forum.

Please take a look at this whole community thread, and see particularly if this tip helps: Opening a ticket with Laptop OEM (ACPI.sys , xperf and latencymon) - #4 by npudar

[Frank1119]

@npudar

ACPI.SYS is a notorious one…

I’m afraid that it is a known issue with (some) Dell XPS laptops, just like @npudar says

[Joey]

I know I am a bit of an extremist regarding this, but I have found that, after using 3 different laptops, you may find issues with any/all of them in one way or another. The BIOS/Motherboard situation seems to be the culprit every time. And since MANY laptops of all manufacturers share the same BIOS, these issues cross pollinate all over the place.

My final solution has been a rock solid one and I do not regret it one bit:

My (hopefully) FINAL live rig solution

Boys and Girls, This is HAL: [HAL Setup] After much frustration with various laptops, HAL is my final answer to the issues that have plagued me over the past 18 months. I am not an engineer or designer…but in my practical use experience, my opinion is (and really has always been) that laptops SUCK. It is simply not logical that a laptop, with everything being miniaturized, can offer the same performance AND reliability that a desktop has to offer. Since I started this endeavor, I have boun…

Yes, I know there might be those who mock the idea…but there is no argument that I have ever found that contradicts the superior build quality, stability, and performance of desktops over laptops at the component level.

Good Luck!

[Mark]

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.

[npudar]

Yes, only CPU affinity testing could’ve helped here. That was my thought in a reply above.

Thank you very much for providing a detailed solution