Don't Cross the Streams...

[RexRed]

I have found that Cakewalk hitches and sputters when I add two graphics cards.

On my motherboard one PCIE 16 slot connects directly to the CPU and that card Cakewalk is fine with.

The other PCIE 16 slot connects to the chipset. This card does not play nicely with Cakewalk.

It seems Cakewalk having graphics streams passing through the chipset seems to add latency to signals.

Anyone else experiencing that? My efficiency cores may be involved in this happening not sure.

Two proton beams shall not be crossed! ?

I am going to test if i defeat the second graphics card in device manager when I am using Cakewalk if that makes any difference.

The hitching and sputtering is very slight and does not effect rendered files and it also does not result in dropouts.

It is okay when this happens but is a bit distracting.

Also, the CPU meters do not seem to spike in any way.

It is just that adding a second GPU stream creates slight latency.

I tried changing affinity and turning off cores and that made things worse.

Please let me know if anyone else has experienced a similar thing.

[Helios.G]

3 minutes ago, RexRed said:

I have found that Cakewalk hitches and sputters when I add two graphics cards.

On my motherboard one PCIE 16 slot connects directly to the CPU and that card Cakewalk is fine with.

The other PCIE 16 slot connects to the chipset. This card does not play nicely with Cakewalk.

It seems Cakewalk having graphics streams passing through the chipset seems to add latency to signals.

Anyone else experiencing that? My efficiency cores may be involved in this happening not sure.

Two proton beams shall not be crossed! ?

I am going to test if i defeat the second graphics card in device manager when I am using Cakewalk if that makes any difference.

The hitching and sputtering is very slight and does not effect rendered files and it also does not result in dropouts.

It is okay when this happens but is a bit distracting.

Also, the CPU meters do not seem to spike in any way.

It is just that adding a second GPU stream creates slight latency.

I tried changing affinity and turning off cores and that made things worse.

Please let me know if anyone else has experienced a similar thing.

If you put your'e configuration setup in your signature, we can see what else you got and maybe help point you in the right direction.

[OutrageProductions]

FYI; I've been running two dissimilar video cards for a decade without any issues, albeit they use the same GPU  Architecture and driver. Never caused any issues with CbB or my video editing sled, probably because I've always run at 48k.

However, I  am currently sourcing candidates for another, newer quad output card so as to be compatible with a Win11 upgrade. $$$$

Edited June 22 by OutrageProductions

[msmcleod]

Sounds like the 2nd graphics card is using the same IRQ as either your audio device or your disk controller.  In the old days, you'd just move it to another PCI slot... but nowadays slots are limited.

Check your motherboard documentation and find out which slots / ports share IRQ lanes, and (if you can) pick a combination that will mean that two high traffic devices aren't sharing the same IRQ.

FWIW - this is why for some users, disabling the network adapter can improve audio performance.  Don't just disable stuff though - check the motherboard docs so you can be deterministic about it.

[Wookiee]

@RexRed can inquire why two GPU's when so many now support up to 4 screens, even at 4K.

[bvideo]

IRQ conflicts used to be a thing. Now not so much. IRQs used to go to "15" on early PC hardware. Now, if you look at your "System Information" under the [-] hardware resources -> IRQs, you see numbers up to 511 at least. And no conflicts.

This was taken care of by hardware improvements in PC architecture, including an "Advanced Programmable Interrupt Controller" and also "Message Signaled Interrupts".

Software improvements include "Deferred Procedure Call" (DPC), which offloads traditional (old fashioned) interrupt processing to lower priorities (and also allowing for use of all the cores to do device servicing).

Nowadays, when looking for hitches and sputters, it is frequently in some DPC, and Resplendence LatencyMon is likely to point out which ones cause the problems. Some older network interface drivers used to be somewhat of a problem, especially if your cable was unplugged, because they would run high priority loops to detect the cable status.