I'm not sure I'm understanding your issue or perhaps I'm not communicating well. The latest trace shows Chrome running and it's using around 30 percent of the computer's CPU processing. For some reason, with the GT 710, Chrome is triggering graphics interrupts that are taking a very long time; almost 6 percent of the core on which the interrupt service routines are running. That's well above the 1 percent maximum they should take. When an ISR is running nothing else can run on that core (unless it's interrupted by an even higher priority interrupt) but no user code will be scheduled until it finishes and the CPU's IRQL drops to 0. That won't happen until pending ISRs and DPCs are finished. Any user threads playing audio will have to wait to be scheduled onto the CPU and if they have to wait longer than 5 milliseconds that could generate an audible audio glitch. Meaning Spotify, Chrome, Groove, etc. - any user process playing audio will have noticeable audio problems in that situation.
Edge is using around 1.19 percent when triggering graphics interrupts in the trace you provided earlier. That's not great but is apparently a short enough time to prevent user programs from having to wait 5 milliseconds so audio glitches won't be noticeable in user processes (Spotify, Chrome, Groove, etc.) I'm guessing that's because Edge seems to be able to use hardware video decoding. Now, I don't know what Chrome is doing in the traces you've provided but I've been assuming playing video. So what I'm hoping to see is a trace captured while audio glitches were occurring but not while using Chrome. My impression so far is that Chrome is hogging CPU resources for some reason while playing video. I'm getting the impression you can easily create audio glitches running Spotify but is that only while using Chrome?