Steve, I think you diagnosed your own problem.
the pan adapter that works is “only” 192KHz bandwidth.
the sdr is up to 10mHz bandwidth!
2 channels (I/Q) or 192KHz is nothing to a modern cpu, it’s pro audio bandwidth stuff and with only 2 channels won’t need much processing, so, low latency. I fact it’s probably using fairly standard audio drivers to deliver the data to the pan adapter code.

but…
you start using an wide bandwidth SDR, it’s going to get real hungry, real fast. 10MHz display/decode bandwidth needs a big chunk of USB bandwidth to deliver it and a big chink of cpu power to make it meaningful, then you have to display it as it’s constantly changing depending on your spectrum/waterfall refresh rates and resolution and… you either drop samples somewhere or you have latency.

This is a common and much discussed issue in digital pro audio circles. Latency between the performers own voice and what they hear is devastating to the performance. Of the sound engineer adds more processing such as equalizers, compressors, etc. to the signal chain there’s more latency.  It wasn’t an issue before digital sound but there was still the delay due to the speed of sound and distance from the pa speakers (about 1ms per foot as a rough guide).

Purpose built software such as spectrum analyzers con concentrate on lower latency but general purpose signal processing software such as an SDR has the goal of ending up with recognizable and copyable signals and hence uses much more processing to achieve that goal, so, low latency isn’t a primary design goal, DSP is.

“Better sdr devoce” is a vague statement. If the device is moving a few MBytes/second of data through a USB port, your going to have latency right there. If the SDR software is any good, there’s more latency. I really doubt that your going to find a reasonable solution at any kind of reasonable cost. It’s just how they work.
Can you not use the built in nulling abilities of the Duo with SDRPlay to do the same thing as the touchy antenna phasing unit? 
The duo is phase coherent for both of its receivers so latency isn’t a factor between them. It’s not just two rap’s in the same box.

You could try throwing a much more powerful computer at the problem. Again, in the pro audio industry they are often purpose built desktop computers specifically put together for high speed computing with bags of memory, multiple very fast cpu’s, solid state disks, and high speed graphics cards with their own large amounts of memory.
All extra garbage is removed or shut down. Add on “virus and internet protection” is removed (the built in one from Microsoft for windows is just fine btw, the rest are just taking money from you and pretending to do something different). All background auto updates are stopped, basically anything that takes a cpu cycle and is t needed for the real job is destroyed with extreme prejudice.

I hate to suggest it on this forum, but, if you have an Nvidia graphics card that qualifies, give SDR-Console a try. It uses the graphics processing chip to offload much of the DSP from the main cpu and is extremely efficient when using the GPU in this manner.

it’s not, specifically, the hardware part of the  radio that’s “at fault” here. It’s a combination of things that have ganged up on you in your specific use. No single “fix” is going to be particularly effective, you have to look at the system as a whole, identify what’s the largest cause of latency and deal,with that. Then move on to the next largest  cause and so on. You also may have to accept that, after spending countless hours and loads of money, it will never be any good as there just too many factors, or there’s a factor that simply cannot be overcome without use specific coding that gives up something else that’s needed.

John:

I'd take this as an opportunity to start using SDR Console. It's a joy to use.

Bob, W4RLS

You just import it from the dialog box.

Bob