Delay/latency questions

[wofritzyt]

Hello,

during my audio experiments I measured the delay from antenna input to audio output.

Setup: ggrx with SDRPlay on ubuntu 16.04

I observe about 200ms delay.

This delay is not from the audio alone, in fact it seems that the processing in gqrx and maybe SDRPlay takes the biggest part.

Is this what can be expected or is there a problem in my setup? What delays do you get with other devices?

Regards,
Wolf DK7OB
 

[Alexandru Csete]

Hi Wolf,

I have never really measured latency because it didn't seem to be a
problem. The only present issue I am aware of is the one with rtl-sdr
dongles using large default buffer sizes at low sample rates:
http://gqrx.dk/supported-hardware#rtlsdr

So, the lesson from there is that libusb based drivers may use large
transfer buffers that will cause increased latency at low sample
rates.

Before I wrote this email I sat down and tried gqrx with the Funcube
Dongle Pro+ on HF. I tried to see if I could notice any latency in the
sound and the audio spectrum while tuning within the passband. Nothing
that I could notice and I think that any latency > 50 ms would be
noticeable.

The frequency translating filter that is used for tuning within the
passband is one of the first processing blocks in gqrx, so I think
this gives a good indication of the processing latency within gqrx
itself.

How do you measure the latency?

Alex
OZ9AEC

[Wolfgang Fritz]

Am 29.07.2016 um 20:22 schrieb Alexandru Csete:
> On Fri, Jul 29, 2016 at 11:00 AM, wofritzyt <wolfgan...@gmx.net> wrote:
>> Hello,
>>
>> during my audio experiments I measured the delay from antenna input to audio
>> output.
>>
>> Setup: ggrx with SDRPlay on ubuntu 16.04
>>
>> I observe about 200ms delay.
>>
>> This delay is not from the audio alone, in fact it seems that the processing
>> in gqrx and maybe SDRPlay takes the biggest part.
>>
>> Is this what can be expected or is there a problem in my setup? What delays
>> do you get with other devices?
>
> Hi Wolf,
>
> I have never really measured latency because it didn't seem to be a
> problem. The only present issue I am aware of is the one with rtl-sdr
> dongles using large default buffer sizes at low sample rates:
> http://gqrx.dk/supported-hardware#rtlsdr
>
> So, the lesson from there is that libusb based drivers may use large
> transfer buffers that will cause increased latency at low sample
> rates.
>

That's interesting. The SDRPlay is using libusb and I am running low
sample rates (500 ksamples/s) when using gqrx as my second amateur radio
receiver. I'll try with higher sample rates.

Basically, the delay is not a problem, but there are situations where I
hear my own transmit signal back and that is extremely confusing. CW is
impossible and phone is difficult because I automatically stop talking
when somebody talks back to me :-)

> Before I wrote this email I sat down and tried gqrx with the Funcube
> Dongle Pro+ on HF. I tried to see if I could notice any latency in the
> sound and the audio spectrum while tuning within the passband. Nothing
> that I could notice and I think that any latency > 50 ms would be
> noticeable.
>

Yes that's right. While delay of 200ms is still OK for tuning, it is
clearly noticeable.

> The frequency translating filter that is used for tuning within the
> passband is one of the first processing blocks in gqrx, so I think
> this gives a good indication of the processing latency within gqrx
> itself.
>
> How do you measure the latency?
>

I connect an RF signal generator to the SDRPlay and my TS5909
transceiver in parallel. Both receivers run in USB mode and are tuned to
give a 1 kHz audio with the RF generator signal.

Then I connect the AF output of the TS590 and the laptop to a 2 channel
digital scope in single shot mode and trigger on the AF signal of the
TS590. So if I switch on the RF at the generator, I can see the delay
between TS590 and gqrx AF signal on the scope.

Regards,
Wolf DK7OB

> Alex
> OZ9AEC
>

[David Ranch]

There is a very similar thread going on in the Airspy email thread:

Subject: airpy sdr# latency
   https://uk.groups.yahoo.com/neo/groups/airspy/conversations/topics/3107;_ylc=X3oDMTM1czhjMWxmBF9TAzk3NDkwNTA1BGdycElkAzg5NzE5MjI0BGdycHNwSWQDMTY5MDA2MzEwOARtc2dJZAMzMTQ2BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQ2OTUzNjA4OQR0cGNJZAMzMTA3

While a bit more Windows / SDR# centric, it too talks about buffer depths but it also talks about different USB transfer methods that have pros/cons to speed vs. latency.  Maybe Linux's libusb can be used in similar ways to minimize the latency?

--David
KI6ZHD

[wofritzyt]

David,
I read the whole thread but couldn't find anything about USB transfer modes. Anyway, there is some discussion in the sdrplay forum regarding USB transfer modes, so I am going to look into this. That's new stuff to learn for me...

[wofritzyt]

FYI, here a screen shot of a delay measurement with a slightly modified setup. I connected a RF microwatt power meter to the RF generator and the receivers and use the DC output of the power meter to trigger the scope. (upper trace). The middle trace shows delay of the TS590, which is abt 10 ms, the lower trace is gqrx and SDRPlay with a USB sound stick as audio device. This stick is extremely bad and needs big buffers to play without underruns. The latency reported by pulseaudio is more than 100ms.

[Greg Troxel]

wofritzyt <wolfgan...@gmx.net> writes:

> I read the whole thread but couldn't find anything about USB transfer
> modes. Anyway, there is some discussion in the sdrplay forum regarding USB
> transfer modes, so I am going to look into this. That's new stuff to learn
> for me...

Thanks for posting your actual measurements with the scope. I'm having
trouble reading the time scale; is that 50 ms/division?

Is this a CW signal and the receiver is in USB or equivalent mode,
already listening, so this is really just steady state processing, vs
squelch?

My impression is that 100 ms of delay or even twice that is really not
bad. I ran gqrx with an nooelec rtl-sdr, and for reasons that are
unclear to me (but are perhaps about lack of X11 optimization) my
computer seemed to be having trouble keeping up. I was hearing about 2s
of delay from speaking into a 446 MHz Ht and hearing audio.

I would be very surprised if the USB bus itself had any significant
delay. I would expect the issues are buffering in many places and
perhaps some batching for FFT computation.

The first thing I'd want to do is add logging for buffer sizes as many
places as possible. I think there is already overflow/underrun
detection; the next thing I would look at is the algorithms for deciding
on the buffer sizes and trying to shrink them.

73 de n1dam

[Wolfgang Fritz]

Am 30.07.2016 um 15:41 schrieb Greg Troxel:
>
...

> wofritzyt <wolfgan...@gmx.net> writes:
>
> Thanks for posting your actual measurements with the scope. I'm having
> trouble reading the time scale; is that 50 ms/division?
>

Yes

> Is this a CW signal and the receiver is in USB or equivalent mode,
> already listening, so this is really just steady state processing, vs
> squelch?
>

Yes it's an unmodulated carrier received in USB mode

> My impression is that 100 ms of delay or even twice that is really not
> bad. I ran gqrx with an nooelec rtl-sdr, and for reasons that are
> unclear to me (but are perhaps about lack of X11 optimization) my
> computer seemed to be having trouble keeping up. I was hearing about 2s
> of delay from speaking into a 446 MHz Ht and hearing audio.
>

That's a lot of delay! Yes for receiving alone 200ms it's OK, even more
as long as the delay does not make tuning difficult. But I am using the
SDRPlay as an auxiliary receiver in my amateur radio station, and here
the delay is quite a problem if you hear your own transmit signal.
Solution would be to mute the receiver during transmission, but I have
not found an easy way to to this so far.

> I would be very surprised if the USB bus itself had any significant
> delay. I would expect the issues are buffering in many places and
> perhaps some batching for FFT computation.
>

At least I have not found a dependency on the sample rate. I can not say
if there is a dependency at all or not.

I don't know if there is any FFT involved in the receive path, but there
is an indication that there is some delay in the audio processing that
you can see in the scope screen shot: Just before the audio signal the
background noise disappears, so the AGC kicks in before the demodulated
audio appears.

> The first thing I'd want to do is add logging for buffer sizes as many
> places as possible. I think there is already overflow/underrun
> detection; the next thing I would look at is the algorithms for deciding
> on the buffer sizes and trying to shrink them.
>

I've done this in the audio driver. The original pulse audio driver
configures a buffer configuration that is far too small for my bad USB
sound stick and even gives underruns with the much better built-in sound
chip.

Right now I am running an experimental audio driver that adjusts the
pulse audio buffer configuration if the underruns are over a certain
limit. This at least makes my USB sound chip usable at the cost of a
higher delay.

Regards,
Wolf, DK7OB

> 73 de n1dam
>