I'm not certain I can trust what I'm seeing. It looks to me as if the dxgkrnl.sys calls to an ISR are regularly exceeding the recommended upper limit of 25 microseconds. The average is 1.5 milliseconds which is not good for overall performance but I see quite a few exceeding 22 milliseconds which would cause audio glitches. One was even 90 milliseconds which is an incredibly long time for an ISR. The above is all happening on core 0 which is where most (if not all) of the audio processing is done.
ISRs can be interrupted by higher priority ISRs but I don't see evidence of that happening. It makes me think the new GPU has a hardware problem.
There is also a span where atapi.sys takes a long time but it's happening on core 1 so shouldn't be interfering with audio playback.
Unfortunately, I'm not sure if capturing the trace is causing some of what I'm seeing. It does have an impact on performance and, if there are not a lot of resources to spare, can actually cause problems during the trace the system wouldn't experience normally. Such as running out of physical memory and hitting the pagefile more frequently.
Did you replace the GPU because you were having problems with the old one?
ISRs can be interrupted by higher priority ISRs but I don't see evidence of that happening. It makes me think the new GPU has a hardware problem.
There is also a span where atapi.sys takes a long time but it's happening on core 1 so shouldn't be interfering with audio playback.
Unfortunately, I'm not sure if capturing the trace is causing some of what I'm seeing. It does have an impact on performance and, if there are not a lot of resources to spare, can actually cause problems during the trace the system wouldn't experience normally. Such as running out of physical memory and hitting the pagefile more frequently.
Did you replace the GPU because you were having problems with the old one?