Re: Latency with RSPduo #rspduo


jdow
 

I'm feeling picky today.

That's MHz ( Mega Hertz) not mHz (milli Hertz ).

Then note that sound is a indeed remarkably light load on a computer. A 16x16 audio matrix with a simple equalizer and adjustable levels and delays on each channel and each matrix cross point is well within a rather old single core processor. The system I am thinking of uses one AudioScience audio card and an Advantech GPIO card for control. It used ASIO audio. It has a 7ms latency end to end WITH all that processing.

If you think about it you MUST be able to perform all the audio processing for a buffer of samples within the time period between received buffers. Otherwise you start running behind. Multiple cores can buy you something if processing can be broken up into independent enough chunks that they can work in parallel. But all the processing still must take only the time between samples. You can buy a little by using larger buffers. Buffer size (64 samples in the case cited) is what sets your latency, The same issue exists with SDRs. And some SDRs use large buffers chiefly in support of the filtering techniques used. When a filter is manufactured by running the signal through an FFT, filtering the results setting frequencies outside the filter's passband to zero, and then using a second FFT to convert back to the time domain you see this trade off directly. If you want to generate a 100 Hz filter you need to collect on the order of 10 ms to 20 ms of data before you can run the FFT. Overlapped FFT is used to reduce that latency a bit. But that latency then becomes a minimum that is supported, Then if you are feeding audio buffers that are large you have that large time delay added to the SDR processing.

In theory SDRs should have the same real delays that analog radios have. Usually it is somewhat longer to several times longer depending on the priority the author places on end to end latency.

Now, if we are talking AirSpy (R2) and not an AirSpy HF+ (Discovery) model then, yes, you require a boatload more CPU. You also will very probably require a dedicated USB bus. An AirSpy at 10 Msps loads the USB bus to between about 3/4 capacity to full capacity. I solve THAT issue with one of the good PCIe plugin USB cards. I have a lot of "stuff" here so the computer currently features a pair of such cards with four USB ports and four USB controller chips onboard. That works a treat. You can tell if something like that is needed by running the AirSpy at one of its lower rates, which are lower bus loads. If there are no skips for that and there are at its full 10 Msps rate and its "packed" transfers option turned on then the separate bus card is needed.

This USB issue does not affect latency, however. It simply addresses data dropouts, clicks. Very often the USB bus CAN impose a practical minimum latency on your project. It works best for these applications for large bulk transfers. Large bulk transfers take time. So there is a trade off in there which is difficult to avoid. If ultra low latency is required you MAY have to find an SDR front end that is a PCIe card or uses Ethernet for transfers. The former is best. Ethernet still has "optimum size" transfer and bus congestion issues.

Your points regarding "turning off all the extraneous junk" is sound. You can sometimes (very often in my experience) gain performance on a given CPU by using task manager to increase priority to above normal or highest. Realtime makes a further improvement but must be used carefully after much testing. With 10 you also cannot get to realtime without administrator privileges, which is an annoying but good thing. (It took some serious clever thinking to get around this limitation for some theme park ride vehicle installations. The nature of the use actually made a clever work around practical.)

{^_^}

On 20210808 09:00:34, Chris wrote:

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.


Join main@SDR-Radio.groups.io to automatically receive all group messages.