Latency

[Eric Allan]

I've got my latency down to less than 100mS, but this is still way too high for QSK CW.

I'm using 4x 64 buffers at 48KHz (5.3mS)

Although I've tweaked some settings in Linrad to minimize latency, Linrad is only using 5-10% CPU with 7/8 cores. I've set priority to 3. I'm sure the latency could be reduced much further if more CPU could be utilized.

Any ideas?

[Eric Allan]

I should have mentioned, I'm using MX Linux.

[Leif Asbrink]

Hello Eric,

latency would not improve even if your CPU were 10 times faster.
A modern computer is really fast.

Latency is determined by your selection of buffer sizes. Disable
the second fft if you do not need the noise blanker.

Have a look at this video:
https://www.youtube.com/watch?v=6R9cg7PpA2s
At 02:50 you can hear someone else between my dots and dashes.

This section on my home page gives info:
http://sm5bsz.com/index.htm
"Time delay in receivers."

I suggest you look at all the links and sub-links. There is much
more than these:

http://sm5bsz.com/lir/rxdel/3-26sdr/sdr.htm
Look at "Performance with parameters for about 30 ms delay."

Process priority = 2
Timer resolution = 1
Input sampling speed = 500000
First FFT bandwidth 1000
First FFT window = 9
First mixer bandwidth reduction = 4
Third FFT window = 8
Third FFT N = 8
Output sampling speed 48000

Settings for 11 ms delay from antenna to loudspeaker using
a Delta44 on Win XP 32 bit using ASIO.
http://sm5bsz.com/lir/rxdel/drivers.htm
(Note that you need to install Delta 44 on a 16 bit win 10 in XP
compatibility mode, 64 bit drivers are not OK for this soundcard.)

73

Leif

> --
> There is an excellent Linrad User Guide by Gaetan, ON4KHG, at:
> http://w3sz.com/Linrad%20Installation%20&%20Configuration%20User%20Guide%20-%20V1-0.pdf
> ---
> You received this message because you are subscribed to the Google Groups "Linrad" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/37d563a7-3b51-4fb8-8624-4f218c7b5c14n%40googlegroups.com.

[Eric Allan]

Thanks Leif,

I thought I understood how all of these setting affect latency, but I guess not.  I figured there was a way to have linrad do all of its processing much faster by utilizing more CPU, which for my radio computer is perfectly acceptable.

Using very similar settings to "Performance with parameters for about 30 ms delay.", I got the latency in single tuner mode much lower, but not enough to go above 25WPM without getting tripped up.  I've noticed that the number for total latency fluctuates quite a bit no matter what mode or single/dual tuner,  0.025 - 0.082 in single tuner mode.  I don't recall the latency extremes for dual tuner mode but it seemed to be centered around 0.160.

 I'm not hearing any glitches or artifacts, does the total latency number normally bounce around?

Does the total latency number account for the D/A buffers for my sound card?

I don't know if I can ever go back to mono/single receiver operation!  I've stayed up too late the past few nights playing around coherent modes, phasing and X+Y mode to reduce QRM, QRN and pull weak stations out of the noise.

73,

Eric

[Eric Allan]

I forgot to mention:

I've had priority set to 3

I do not have the option to set timing resolution.

I am using expert mode.

[Franco Venturi]

Eric,

since you mention 'single tuner mode' and 'dual tuner mode' in your message, I guess you are using an RSPduo with the sdrplay3 driver.

If this is the case, a couple of days ago I fixed a bug related to the way the buffers are passed from the sdrplay3 stage to the next stage ('timf1p'), that Rick Kunath discovered when trying to save a raw I/Q file with Linrad in dual tuner mode. Rick is out of town these days so he hasn't had the chance to verify that the fix works for him (it does work for me); perhaps you could try it there to see if it helps with your latency problem.

You can find the latest release here: https://github.com/fventuri/linrad/releases/tag/5.01-999-sdrplay3-20230115

Also I am not sure what input sample rate and decimation you are using for your tests, but I think it would be interesting to see what happens if you change the decimation factor (and therefore the actual input sample rate as seen by Linrad).

73,

Franco

[Eric Allan]

Hi Franco,

Yes I'm using a RSPduo. I just tried your latest version.  I didn't notice any difference in latency or the erratic total time on the timing display.  I will experiment with changing the decimation factor.  I've got things cranked down but in practice that isn't always the best.

Thanks es 73,

Eric

[Leif Asbrink]

Hello Eric,

The latency fluctuations are probably due to large I/O buffers.
The buffer sizes are controlled by the DMA rate. You can force
a high DMA rate, maybe 1000 Hz for input as well as output.

Obviously that is the rate at which Linrad sends/requests data
from the device driver. It depends on the driver whether it
actually uses the size requested by Linrad or whether it uses
a larger (or smaller) buffer for the actual communication
with the hardware.

82-25=57 so it seems you have an extra 50 ms of buffers, maybe
DMA rate 25 ms for input as well as output?

Press 'T' to display timing info. You will see where time delay
comes from and at what point(s) delay varies.

What do you see?

73

Leif

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/7a5bac31-e369-4696-8b04-dbf71484a97cn%40googlegroups.com.

[Eric Allan]

Hi Leif:

Third FFT size number does not change and always shows zero even though pressing the button to reduce it does have an affect in reducing latency.

From timing window:

A/D:250000Hz (+/-12) D/A:48001 sync:~ -0.016 - +0.028
DMA:      A/D:1953 Hz   D/A:1500Hz

          Delay Times
D/A         0.001       MIN    0.002
baseb    ~0.001      buf  0.022-0.082
timF3    ~0.015      fft3  0.000-0.003
Raw   0.001-0.004 fft1  0.000-0.003
1.54%  (2%)            Tot  0.045-0.106

With output sound card disabled and no other parameters changed:

A/D:250000Hz (+/-12) D/A:48001 sync:~ -0.016 - +0.028
DMA:      A/D:1953 Hz   D/A:1500Hz

          Delay Times
D/A          0.001     MIN    0.341
baseb    ~0.001     buf  0.002-0.004
timF3    ~0.015     fft3  0.000-0.003
Raw   0.001-0.004 fft1  0.000-0.003
1.54%  (2%)             Tot  0.018-0.026

Playing around with different DMA rates, I noticed that the ratio between A/D and D/A lands at around 2.6, which makes sense as 250/48 is 5.2. This didn't change latency much unless I went really low.

It looks like the output sound device is the bulk of the latency.

Please advise if you see additional room for improvement with settings or if I should get a USB audio interface on order?

Thanks,

Eric

More info below:

From par_cw:

First FFT bandwidth (Hz) [100000]
First FFT window (power of sin) [9]
First forward FFT version [0]
First FFT no of b threads [0]
First FFT storage time (s) [1]
First FFT amplitude [2000]
Main waterfall saturate limit [0]
Enable correlation spectrum [0]
Enable second FFT [0]
First backward FFT version [0]
Sellim maxlevel [12000]
First backward FFT att. N [6]
Second FFT bandwidth factor in powers of 2 [2]
Second FFT window (power of sin) [2]
Second forward FFT version [0]
Second forward FFT att. N [7]
Second FFT storage time (s) [5]
Enable AFC/SPUR/DECODE [0]
AFC lock range Hz [0]
AFC max drift Hz/minute [100]
Enable Morse decoding [0]
Max no of spurs to cancel [0]
Spur timeconstant (0.1sec) [5]
First mixer bandwidth reduction in powers of 2 [2]
First mixer no of channels [1]
Third FFT window (power of sin) [8]
Baseband storage time (s) [5]
Output delay margin (ms) [45]
Output sampling speed (Hz) [48000]
Default output mode [3]
Audio expander exponent [3]
Baseband waterfall saturate limit [0]
No of averages in meter.txt [0]
A/D speed [250000]
Check [10415]

Output is jack @ 4x64 buffers to onboard sound.

DMA min=1000 max=2000

[Leif Asbrink]

Hello Eric,

It seems Linux MX uses pulseaudio:
https://eirenicon.org/knowledge-base/fix-sound-setup-on-mxlinux/
pulseaudio is a bad idea for latency.

73

Leif

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/eb80c04e-c708-4a32-b1b2-ba2cf1a4cadfn%40googlegroups.com.

[Eric Allan]

Hi Leif,

Thanks Leif,  I had already disabled pulseaudio, been using jackd, but just to be sure, I completely removed Pulseaudio  from the system with no significant change.

73,

Eric

[Leif Asbrink]

Hi Eric,

I do not think jackd is designed for low latency. You should use
the hardware driver directly. You might use ALSA as described at
eirenicon.org or 4Front OSS http://www.opensound.com/oss.html

73

Leif

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/2202c27e-763a-48ae-baa7-335c9e2b016en%40googlegroups.com.

[Eric Allan]

Hi Leif,

Thank you for your response.  Jack is commonly used in the linux pro audio world for low latency, live monitoring in digital audio workstations. I've been using it for years in that realm.  Years ago I did some tests using a scope and a pulse generator.  The latency was entirely  related to the sample rate, buffer sizes plus a fixed delay from the hardware itself.  The fixed delay was the same regardless of buffer size or sample rate.

The limitation in the pro audio realm is having enough CPU to do the desired processing without having buffer over/under runs at the desired buffer size. When the CPU load is high we have to use larger buffers which add latency.  That's why I was asking in my first post if there was a way to make linrad use more CPU to finish it's computations faster.  But I suspect my on-board audio, which I would never even think of using in a digital audio workstation, has a large fixed delay, so linrad has plenty of time to process without running out of time to fill the next buffer.

[Eric Allan]

I need to make a correction, looking at my notes, the fixed hardware delay was a fixed number of samples, not a fixed time delay.

[Leif Asbrink]

Hello Eric,

What is the actual hardware driver you use? jackd does not have any
driver of its own as far as I understand, it is connecting one software
that produces an audio stream to another software that consumes the audio.

That necessarily introduces some needless delay, maybe very small, but
not necessary. The important thing is that the hardware driver typically
introduces a delay because of hardware settings. Those might be unreachable
through jackd. What is the sound system you use with jackd?

Output is Linrad, but what is the input to jackd?

I suggest you connect a pulse generator to your soundcard and connect
its input to its output through jackd and look with an oscilloscope.
Beware that jackd could be oversmart and enable the direct connection
of input to output inside the hardware. Best would be to use separate
soundcards for input and output.

73

Leif

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/4f4f720a-524c-4296-bafb-e048df834bb8n%40googlegroups.com.

[Eric Allan]

HI Leif,

I'm using an RSPduo going in, on-board sound card for audio out. I've been using Jack for years because of it's flexibility, which is probably not necessary in this particular use case. I should have said I'm using ALSA via jack, since Jack will use ALSA when interfacing with the outside world. Jack does not add any latency:

https://jackaudio.org/faq/no_extra_latency.html

Jack gives access to a lot of sound card settings, but I have never connected to ALSA directly, so perhaps there could be something missing.

One thing I had not considered is the latency could be be on the input side.  I don't know how much latency there is from the RSPduo itself or how the buffers get set/handled by Franco's version of Linrad. He is aware of this thread, so I think that if there was considerable latency on the input side, he would have said something already.

[Rick Kunath]

Remember Eric too that the Duo is using the SDRplay Linux API. So that
is in series with the data stream from the Duo too.

Rick Kunath

[Eric Allan]

Thanks Rick, I had forgotten about that.

[Franco Venturi]

I think the total latency of a chain of 'blocks' can be expressed as the sum of the latency for each block where the latency of a block is very roughly the 'buffer size' for that block divided by the sample rate that the block runs at. By 'buffer size' I mean the actual buffer size for a source block (like the sdrplay3 module), the number of taps (or better half the number of taps) for a FIR filter, the FFT size for a FFT filter and so on; you get the idea.

With this in mind input blocks like the the sdrplay3 module 'usually' tend to contribute less to the total latency because their 'block size' is divided by a very high sample rate (say 2Msps) compared to the sample rate of the output stage (that typically runs at 48 or 96kHz). For instance the block size used in the sdrplay3 module ('snd[RXAD].block_bytes') is 128k bytes in dual tuner mode, which means 16k I/Q samples per channel; at a sample rate of 2Msps, the latency added is therefore 16k / 2M = 8ms (if my math is right).

A good way to validate this point would be to change the sample rate of the input stage (for instance changing the decimation factor from 1 to 2) without changing the sample rate of the output stage; if the contribution of the input stage to the total is almost negligible then the total latency should hardly change; however if the latency of the input stage was the dominant factor, then the total latency should almost double.

Franco

[Eric Allan]

Thanks Franco for the explanation.

[Leif Asbrink]

Hello Eric!

When you press B in the Linrad I/O setup you should have one
option to select the ALSA driver for your soundcard. You might
have more than one alternative.

What are the parameters shown for the ALSA driver(s)?
Try to select it, then set the highest output sampling rate for
the mode (CW).

The baseband sampling rate is the input rate divided by the
first mixer bandwidth reduction. With 2 MHz from the RSP Duo
and first mixer bandwidth reduction in powers of two = 5 (32)
your baseband rate would be 62.5 kHz. 0.016 ms per sample.
With an fft3 size of 7 (128) the buffer delay would be 2 ms

I find it unbelievable that jackd would not cause any delay
at all. As far as I understand it can be used as an audio
mixer and it has a resampler to compensate for differences
in sampling rate between input and output. Some buffering
must be necessary.

73

Leif

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/cb9e2a62-5d5b-46ef-8d0f-f8af3cf62314n%40googlegroups.com.

[Eric Allan]

Hi Leif,

Thank you for taking the time to work with me on this.

Jack does not do any resampling.  I think Jack would be more accurately described as an API to control sound card settings and a patchbay for inter connecting different software to each other and/or various sound card inputs and outputs, using the same sample rate and buffer settings that jack is set to. It's very commonly used in the linux audio recording realm. I've used it to record instruments I'm playing while listening through the whatever recording software jack is routed to.  Playing with different sample rates and buffer sizes, I start to feel a difference around 7-8mS and going much above 12mS input to output feels quite awkward. 

I used ALSA directly with no noticeable change.  Changing to the settings you recommended increased totally latency displayed when pressing "T" by about 40mS on average.  I have been running the RSPduo at 2MHz, with an IF bandwidth of 200KHz.

[Leif Asbrink]

Hi Eric and Franco,

When you connect one soundcard to another the software
has to apply a resampler in order to compensate for
small differences in the sampling speed. That can be
done with small buffers, but I see no way to do it without
buffers.

My motherboard device is HDA Intel PCH ALC887-VD When using
it for input as well as output to Linrad, the delay is 8 ms
at 96kHz sampling in both directions.

With the I option and my RSP1 the delay is about 15 ms which
is similar to what i see with the rtl-sdr dongle.

With the S and T options the delay is around 60 ms, and unstable.
I think that is because of the driver, it can do I/Q balancing
which means it is doing an fft.

There is not really a need for the fft to cause a delay. It is possible
to use the old coefficients for linear combining I and Q and send
the buffer to the PC while storing a copy of the original buffer
and then do the fft for updating the coefficients. It is the long
term average that is needed anyway. The small drawback would be
that the response of the balancing would be a trifle slower
when a strong signal suddenly appears.

The static balancing that Linrad provides is probably good enough,
I do not think it varies much with temperature or frequency.

73

Leif

[Franco Venturi]

Leif, thanks for your observations.

It's getting a little late here so I just had a few minutes to take a quick look at the receive callback code for the I option (https://sourceforge.net/p/linrad/code/HEAD/tree/trunk/mirics.c#l320):

if( (ui.rx_input_mode&BYTE_INPUT) != 0)

{

   for(i=0; i<len; i+=2)

   {

     iz=(short int*)&timf1_char[timf1p_sdr];

     iz[0]=((short int)buf[i ])<<8;

     iz[1]=((short int)buf[i+1])<<8;

     timf1p_sdr=(timf1p_sdr+4)&timf1_bytemask;

   }

}

else

{

   ll=len/2;

   for(i=0; i<ll; i+=2)

   {

     iz=(short int*)&timf1_char[timf1p_sdr];

     iz[0]=buf16[i];

     iz[1]=buf16[i+1];

     timf1p_sdr=(timf1p_sdr+4)&timf1_bytemask;

   }

}

if( ((timf1p_sdr-timf1p_pa+timf1_bytes)&timf1_bytemask) >= snd[RXAD].block_bytes)

{

   lir_set_event(EVENT_HWARE1_RXREADY);

}

and it is similar to the code for the T option in single tuner mode (which is the mode option I uses) (https://github.com/fventuri/linrad/blob/main/sdrplay3.c#L3193):

for (i = 0; i < numSamples; i++) {
   iz = (short int*)(&timf1_char[timf1p_sdr]);
   iz[0] = si[i];
   iz[1] = sq[i];
   timf1p_sdr = (timf1p_sdr + 4) & timf1_bytemask;
}
if (((timf1p_sdr - timf1p_pa + timf1_bytes) & timf1_bytemask) >= snd[RXAD].block_bytes) {
   lir_set_event(EVENT_HWARE1_RXREADY);

}

As you can see, they  both use the 'timf1p_sdr' buffer and they both trigger the event 'EVENT_HWARE1_RXREADY' after snd[RXAD].block_bytes

I haven't printed out the actual value of snd[RXAD].block_bytes to see if it is different (and that might explain the difference in latency); also as Rick noticed, in the case of the SDRplay proprietary driver there's some processing between the device and when the I/Q values are presented to the callback; unfortunately I do not really have much visibility and knowledge on that initial part.

73,

Franco

[Leif Asbrink]

Hi Franco,

I think the proprietary drive routine from sdrplay uses a buffer
that spans something like 50 ms, uses an fft and then sends
the buffer in the block size the user asked for. This implicates
that data comes in bursts which explains why the delay is
so unstable.

You might call (double)t=current_time() or (int)i=ms_since_midnight()
each time a block arrives to test my hypothesis.

73

Leif

> --
> There is an excellent Linrad User Guide by Gaetan, ON4KHG, at:
> http://w3sz.com/Linrad%20Installation%20&%20Configuration%20User%20Guide%20-%20V1-0.pdf
> ---
> You received this message because you are subscribed to the Google Groups "Linrad" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linrad+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/8872b84c-4665-471b-8200-41bf281018ebn%40googlegroups.com.

[Franco Venturi]

Leif,

you have a very valid point.

Tonight I added some simple code to measure the time between two successive calls to the RX callback function in single tuner mode (https://github.com/fventuri/linrad/blob/measure-latency/sdrplay3.c#L3204-L3214).

I then ran Linrad for a few seconds saving to file the output from the print statement I added.

I saw that with a sample rate of 2Msps the RSPduo always calls the receive callback function every 252 samples. One would therefore expect the time between two successive calls to the RX callback to be around 252 / 2M =  126 us (i.e. 126000ns); however the output shows that most of the times that time difference is much smaller (say 30000-40000 ns) except every 96th time where that time difference is always above 30ms, and in some cases it is even > 60ms.

To explain better what I see, these are the first 20 lines of that debug information; the first column is the sequence number of the RX callback, then the number of samples for that callback (always 252), and the last column is the time difference in ns.

96 252 43517032
192 252 46181352
288 252 42418773
384 252 46571828
480 252 45376541
576 252 44356388
672 252 43254178
768 252 46785565
864 252 43535838
960 252 42388481
1056 252 42314556
1152 252 51951074
1248 252 32296268
1344 252 52117199
1440 252 31504707
1536 252 41745646
1632 252 41478764
1728 252 41913661
1824 252 45629131
1920 252 42006471

...

I think these numbers show your hypothesis is correct.

If anyone wants to try, the code I ran tonight is in the 'measure-latency' branch (https://github.com/fventuri/linrad/tree/measure-latency).

73

Franco

[Earl Shaffer]

Hi Franco.

I found that when I had network trouble, the data was unstable. When looking near a strong (near saturation) signal, there were strong noise sidebands present during each glitch. It might be interesting to make that test.

Earl Shaffer, WB9UWA.

To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/7e91009a-d1f7-45bb-83bd-08d453969284n%40googlegroups.com.

--

Earl Shaffer,  WB9UWA

 

My EME array photos

https://www.dropbox.com/sh/bbn2ktonko8e3az/AACHBBOhf6Djk5Pf2c86Br5ja

Detailed array photos

http://www.gm4jjj.co.uk/WB9UWA/

Facebook

http://www.facebook.com/earl.shaffer

Linkedin
http://www.linkedin.com/pub/earl-shaffer/12/881/735

[Franco Venturi]

Correction - last night after I went to bed I thought again at those time differences every 96th callback, and the delay values didn't look right: at 2Msps the time it takes to go though 96 x 252 samples should be 96 x 252 / 2M = 12.096ms, not the 40-50ms I was seeing. Since the values from the debug prints were about 4 times the values I would have expected, I suspected I was running with a decimation of 4, i.e. with an actual sample rate of 500ksps.

This morning I confirmed that last night output was at a sample rate of 500ksps; my apologies for that mistake.

This morning I also reran the same code with decimation turned off (i.e. sample rate = 2Msps), with AGC turned off and with DC offset correction and IQ imbalance correction both turned off (and all the notch filters turned off) to rule out all of those settings, and I still see the same behavior I saw last night: each RX callback receives 1008 (=4x252) samples this time, but every 96th call to the RX callback there's a very significant time difference that is on average 48ms (=96 x 1008 / 2000000):

96 1008 47568784
192 1008 47100459
288 1008 45555853
384 1008 46997882
480 1008 46496452
576 1008 45515499
672 1008 56406053
768 1008 35862932
864 1008 47062785
960 1008 45806295
1056 1008 46582388
1152 1008 46151710
1248 1008 46884477
1344 1008 46356965
1440 1008 47543957
1536 1008 46191968
1632 1008 46517479

...

Earl,

I am not sure what you mean by having "network trouble"; all the tests I ran last night and this morning do not use any network, since the RSPduo is directly connected via USB to my PC where Linrad runs (and the SDRplay API service uses shared memory and semaphores to communicate with the libsdrplay_api library loaded by Linrad when option T is selected).

73,

Franco

[Earl Shaffer]

Hi Franco,

I am not suggesting that you have network trouble. Your timing issues may give the same result that I had when I had network trouble.

When there is discontinuity in the data, I would expect IMD products from a strong signal.

In my case for 2 meter EME, I use an IQ+ to a Delta44 soundcard and use Linrad in an XP computer. Modern drivers do not work well with the Delta44 sound card. Map65 version 3.0 will not run on an XP computer so I use a LAN network to send data from the XP computer to the Windows 10 computer.

Initially I had regular network dropouts which resulted in IMD products from strong signals. I had to change over to a USB network 'card' on the XP computer to solve the network dropouts. Without these dropouts in data, I can experience the full dynamic range that the system is capable of.

The test that I suggested would verify the timing issues and may suggest how serious the issue is for dynamic range. I would be curious to see that result. The RSPduo is a potential solution for my 2 meter EME dual polarity system. The wider bandwidth may improve my noise blanker performance on Linrad. It would also get rid of the extra computer.

Earl Shaffer, WB9UWA.

To view this discussion on the web visit https://groups.google.com/d/msgid/linrad/168be72f-7c59-4f1f-83a1-e5f6209989d8n%40googlegroups.com.

[Franco Venturi]

Earl,

I honestly don't think it is a matter of discontinuity of the data in this specific case, but it is just the fact that the SDRplay API somewhere 'holds' the samples for about 48ms (on average), and then releases them; imagine for instance that it had an internal buffer capable of storing the I/Q samples for about 48ms and, once that buffer is full, it sends the value downstream to the sdrplay3 code in Linrad. Unfortunately I do not know much of the internals of the SDRplay API because it is proprietary, but Leif thinks this buffer is used for an FFT.

Regarding the issue of discontinuity in the data, i.e. missing/dropped samples in the I/Q stream, they are very easy to detect because each RX callback is passed an argument called 'params' that contains a pointer to a structure of type 'sdrplay_api_StreamCbParamsT', and one of the fields in that structure (called  'firstSampleNum') contains the sequence number (modulo 2^32) of the first sample in that RX callback. When there are no dropped samples that value should be exactly equal to the value of 'firstSampleNum' for the previous invocation of the RX callback plus the number of samples (argument 'numSamples') for the previous RX callback. If these numbers do not match, it means some samples are lost and it is also easy to compute how many were lost.

I have this kind of check in some sample code I wrote (see here for example: https://github.com/fventuri/dual-tuner-experiments/blob/main/dual_tuner_recorder.c#L778-L788); perhaps it would alsobe  useful to have something similar  in the sdrplay3 module in Linrad.

73,

Franco

[Eric Allan]

Looks like most of the latency is the SDRplay API, which is helpful to know as I consider what options are.

Thanks Leif and Franco for your help.