I’ve tried both a Dell XPS 13 2 in 1 and a MS Surface Pro 7. I would like to run Gig Performer on a Windows machine but LatencyMon keeps reporting there will be issues with audio dropouts due to driver problems. I’ve tried all the CPU tweaks which prevent the CPU from automatically stepping up and down. I’ve disabled unncessary drivers. And still, both machines exhibited issues with ACPI.sys and wdf01000.sys.
I’m frustrated and ready to jump to Mac.
What AudioIntergace are you using?
How is your samplerate and samplebuffer?
Are you using an ASIO driver?
Is gig performer the only running program using that audio interface?
Hi there! Thanks.
I currently don’t even have an audio interface connected. And local audio is disabled. And LatencyMon reports problems before any audio interface is even connected. That has me concerned.
Are you using asio?
How looks your audio setup in Gig Performer?
Network drivers and video drivers are the usual culprits for spikes.
Can you post a screenshot of your LatencyMon reports?
The whole point of decent audio interfaces is that they include low latency drivers. How exactly does LatencyMon report an issue when it doesn’t even know what driver is going to be used?
@dhj LatencyMon doesnt need to know which audio drivers are being used. It’s measuring faults in the timely deliveries of other requests made within the WIndows architecture, faults which can often cause audible pops or clicks in real time audio, regardless of which audio drivers are used.
Will generate a new one shortly. Thanks for your attention. I appreciate it.
OK – have you actually tried using Gig Performer on your Windows machine along with a decent user interface?
I run Gig Performer on a Surface Pro 4 (with a Focusrite 18i20 gen 2) and don’t have clicks, pops, or dropouts.
But as mentioned earlier, wifi and physical network activity can cause glitches. If you’re running multiple monitors, especially extended desktops, you’re also more likely to get glitches on any machine.
Hard to give any further tips without seeing what LatencyMon is saying.
Here’s my latest result:
CONCLUSION
Your system seems to be having difficulty handling real-time audio and other tasks. You may experience drop outs, clicks or pops due to buffer underruns. 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 13:31:28 (h:mm:ss) on all processors.
SYSTEM INFORMATION
Computer name: TABLET-N9UQINOA
OS version: Windows 10, 10.0, version 2009, build: 19042 (x64)
Hardware: Surface Pro 7, Microsoft Corporation
CPU: GenuineIntel Intel(R) Core™ i7-1065G7 CPU @ 1.30GHz
Logical processors: 4
Processor groups: 1
RAM: 15970 MB total
CPU SPEED
Reported CPU speed: 1498 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): 1103.40
Average measured interrupt to process latency (µs): 10.312128
Highest measured interrupt to DPC latency (µs): 1028.50
Average measured interrupt to DPC latency (µs): 3.089149
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): 110.257009
Driver with highest ISR routine execution time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Highest reported total ISR routine time (%): 0.000519
Driver with highest ISR total time: Wdf01000.sys - Kernel Mode Driver Framework Runtime, Microsoft Corporation
Total time spent in ISRs (%) 0.000519
ISR count (execution time <250 µs): 106114
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): 698.120828
Driver with highest DPC routine execution time: ACPI.sys - ACPI Driver for NT, Microsoft Corporation
Highest reported total DPC routine time (%): 0.031416
Driver with highest DPC total execution time: rspLLL64.sys - Resplendence Latency Monitoring and Auxiliary Kernel Library, Resplendence Software Projects Sp.
Total time spent in DPCs (%) 0.092686
DPC count (execution time <250 µs): 17708696
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-10000 µs): 35128
DPC count (execution time 1000-2000 µs): 0
DPC count (execution time 2000-4000 µs): 0
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: system
Total number of hard pagefaults 6905
Hard pagefault count of hardest hit process: 2420
Number of processes hit: 22
PER CPU DATA
CPU 0 Interrupt cycle time (s): 615.216649
CPU 0 ISR highest execution time (µs): 110.257009
CPU 0 ISR total execution time (s): 1.011295
CPU 0 ISR count: 106114
CPU 0 DPC highest execution time (µs): 623.277036
CPU 0 DPC total execution time (s): 138.303991
CPU 0 DPC count: 15403163
CPU 1 Interrupt cycle time (s): 413.510975
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 644.176903
CPU 1 DPC total execution time (s): 15.441697
CPU 1 DPC count: 1163006
CPU 2 Interrupt cycle time (s): 243.954067
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): 605.834446
CPU 2 DPC total execution time (s): 6.571032
CPU 2 DPC count: 413783
CPU 3 Interrupt cycle time (s): 297.130660
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): 698.120828
CPU 3 DPC total execution time (s): 20.191093
CPU 3 DPC count: 763872
I repeat my question. Have you actually tried using Gig Performer? And if so, what happened?
Yes. There are audio dropouts with an ASIO audio interface. And they appear in latency monitor regardless if the audio interface is connected. Because they are caused by the operating system not the audio interface. This is the kind of stuff LatencyMon was designed for testing.
And what happens when you use this with gig performer,
Still issues?
Which audio interface? You said earlier you weren’t using an audio interface. You are probably never going to get decent real-time audio behavior from the internal sound card on a regular Windows machine.
What sample rate and buffer size are you using?
Also, with which plugins are you having this problem?
What does the CPU utilization in Gig Performer report?
Just to put all this in context, you left LatencyMon running for over 13 hours and it’s telling you that at some point in that 13+ hours at least one processor core experienced an interrupt that lasted for just a bit over 1 ms.
On my audio system I just ran LatencyMon 7.0 (the latest) to see what it said. It went about 3 minutes before telling me my system wasn’t suitable for real time audio.
And yet I use it every day without problems. For several years.
I wouldn’t get too hung up on what LatencyMon says.
What I would conclude from your report is that your Surface Pro 7 is better for real time audio than my desktop machine with an i5-8700K running 4.8 ghz. I don’t believe it, but that’s what it’s saying.
If you want to obsess about what it’s actually telling you, it’s telling you that ACPI.sys is a problem, and because ACPI.sys is part of the windows kernel there is no escaping it. Yet, somehow, people manage to use it.
To quote Yogi Berra,
“In theory, there’s no difference between theory and practice.
In practice, there is!”
In other words, screw that LatencyMon and just use the product with a decent audio interface and you should be just fine!