Capture Stutter - AMD

We have been seeing an intermittent issue with most blackmagic decklink devices when used with integrated graphics chipsets from AMD. The issue that we see is an intermittent "stutter" on capture that is visible in media express and our own application that uses the black magic drivers.

This doesn't seem to be related to hard drive speed in any way because we're only using the capture so we can output the SDI source on displayport. We are not recording to disk.

We are only using one input on the duo 2 and decklink 12G. Both are capturing 1080p59.94, but the issue is also present at 720p59.94

System1:
DFI-ITOX BE170 motherboard (AMD RX-427BB processor, AMD Radeon HD9000 graphics)
16GB DDR3 SDRAM, 1600Mhz
Micron MTFDDAK1T0TBN - 1AR12ABYY SSD
Blackmagic Designs Decklink 12G
Blackmagic Designs Decklink Duo 2
Desktop video 11.5.1
Windows 10 LTSC x64

System2:
DFI-ITOX GH171 motherboard (AMD® Ryzen™ Embedded V1807, Quad Core, 3.35GHz, Radeon Vega Graphics)
16GB PC4-3200 DDR4 RAM
Intel SSDPEKNW010T8X1 NvME SSD
Blackmagic Designs Decklink 12G
Blackmagic Designs Decklink Duo 2
Desktop video 11.5.1
Windows 10 LTSC x64

Not a solution, but just for the sake of debugging if this is OS/driver related, would you try to boot a Linux live session from USB in RAM (less risk of altering your current system) and see if the problem exists there as well? If you know all the commands, prepared a boot disc/downloaded drivers you could be testing in less to 10 minutes... but a first timer will probably take an hour. I'm personly interrested since our organisation also switched to AMD r9 3900x with b450 and x570 chipsets and the decklink cards are still on order...

If you're interrested I can describe the steps/precautions to take?

Don't have any virtualization software installed, I have had problems with decklink API when HyperV is also running a VM in the background.

Not a solution, but just for the sake of debugging if this is OS/driver related, would you try to boot a Linux live session from USB in RAM (less risk of altering your current system) and see if the problem exists there as well? If you know all the commands, prepared a boot disc/downloaded drivers you could be testing in less to 10 minutes... but a first timer will probably take an hour. I'm personly interrested since our organisation also switched to AMD r9 3900x with b450 and x570 chipsets and the decklink cards are still on order...

If you're interrested I can describe the steps/precautions to take?

That's a good idea. I'll give that a shot.

Don't have any virtualization software installed, I have had problems with decklink API when HyperV is also running a VM in the background.

Nope. Just the OS and nothing else.

Thanks

Don't have any virtualization software installed, I have had problems with decklink API when HyperV is also running a VM in the background.

Some hardware like ethernet NIC's can be affected by not running a VM at all but just having the IOMMU / VTd BIOS/UEFI features enabled.

It maybe a good idea to also consider these options besides the PCIE ASPM powersaving options which may also affect Decklink/Intensity stability in a bad way the next time with debugging.

That's a good idea. I'll give that a shot.

Just bump this topic if you need any hints for testing on a live USB Linux in ram session.

Sorry to dredge this old thread up. I thought that we had the issue more or less resolved when amd updated the chipset driver. It seems that I was wrong, though. Certain kinds of content still shows a definite "stutter" during capture.

Things I've tried:
- Latest Desktop video (12.0)
- Latest AMD Chipset / graphics driver (20.50.23.01)
- Disabled ASPM and IOMMU
- Tried a similar PCIe SDI capture card from another manufacturer and it worked fine.

Any further help would be appreciated.