I’ve spent this morning revisiting the buffering for SDRplay devices and found an area where I’ve been able to greatly improve the latency but buffering the data from RSP devices (indeed most SDRs) is essential as there’s no guarantee that they reliably return data at the selected sample rate. Even a difference of 0.01% causes problems, the SDR can overrun or underrun. I notice the data rate change gently as the device warms up, once warm it’s stable.
Anyway, the latency is now much better, I’ve also given the priority of the SDRplay service (sdrplay_apiService.exe) a boost to high which IMO should be done as the default priority of Normal requires sharing resources with programs such as browser.
This priority change and the coding changes have helped, there will be a kit for the test team later today, tomorrow at the latest.
From: main@SDR-Radio.groups.io <main@SDR-Radio.groups.io> On Behalf Of Simon Brown
Sent: 19 August 2021 06:50
Subject: Re: [SDR-Radio] Latency with RSPduo #rspduo
Looking at the SDRplay support in SDR Console I see old code from the first version with 100ms buffering, the more recent SDRplay APIs (V3) have very, very low latency so I’ve just removed the need for this buffering.
This change will be in the next update to v3.1.
Totally unscientific measurement:
SDR-duo to SDR Console 3.1 to WSJY gave average DT of 800 ms
RX-888 to SDR-console to WSJT gave average DT of 300 ms.
Console 3.1 was showing audio of 55ms
Computer time from local university SNTP server and Dimention 4.
Both these are more than usual . Last time I looked it I saw less than 100ms for RX-888 path and 300 for SDR-Duo path. Of course one is from USB2 port and one from USB3.
Sent from Mail for Windows