rtl_fm and buffer underruns

[waismocha]

 I have an rtl-sdr USB stick receiver and using Linux.  I'm fascinated by the command line rtl_fm program and its flexibility to scan frequency ranges and pipe out the audio stream.  I have a lot of buffering and squelch problems and was wondering if this is normal or if there is anything I can try.  I tried piping the audio to both sox and aplay.  Sox has some major issues with underruns and aplay is not that much different but is slightly better.  Here are some examples of the commands I'm running.

$ rtl_fm -N -f 460M:462M:12.5k -s 48k -l 140 -o 3 | aplay -r 48k -f S16_LE -t raw -c 1

The above produces output messages like this as I hear the squelch open to static:

underrun!!! (at least 480.479 ms long)
underrun!!! (at least 1439.395 ms long)
underrun!!! (at least 289.042 ms long)

If I substitute sox for playback like this:

$ rtl_fm -N -f 460M:462M:12.5k -s 48k -l 140 -o 3 | play -t raw -r 48k -e signed-integer -b 16 -c 1 -V1 -

I get squelch pulsing that seems to be due to some underrun problem.

I've tried tweaking the oversample, squelch, and sample rate parameters and they make very little difference.  Are the rtl-sdr USB sticks notorious for not being able to supply data fast enough?  On this same systems with same USB stick, GUI programs like gqrx has no problems, sdr-sharp has some rare problems, and HDSDR via Wine and BorIP server has some frequent problems that are solved by stopping and starting the playback.  Whatever gqrx is doing to manage the incoming data seems to be the most effective on my hardware.  I am running pulseaudio on this box if that matters.  Thanks for any suggestions.

[Alexandru Csete]

Hi,

By default Gqrx uses pulseaudio and it could be that pulseaudio is more tolerant to underruns. aplay is for ALSA and I think sox and wine use ALSA too. You can try to use the pulseaudio version called pacat:

rtl_fm -f 460M:462M:12.5k - | pacat --format=s16le --rate=24000 --channels=1 --latency-msec=100

In this case it will also show up in pavucontrol and the output will be available for capture by other applications such as fldigi.
pacat can also stream to a remote pulseaudio server so there are many interesting possibilities.

Alex

[Adam Nielsen]

> Here
> are some examples of the commands I'm running.
>
> $ rtl_fm -N -f 460M:462M:12.5k -s 48k -l 140 -o 3 | aplay -r 48k -f S16_LE -t
> raw -c 1

Not sure whether this will affect anything, but note that -s sets the
bandwidth of the signal you are receiving. If you're listening to NBFM
signals you probably want a smaller value or you will get more noise. You
should use -r to set the audio sampling rate to 48k to match aplay, so that
you can set -s to match the signal you are trying to receive. It looks like
it should be -s 12.5k in your case.

> underrun!!! (at least 480.479 ms long)
> underrun!!! (at least 1439.395 ms long)
> underrun!!! (at least 289.042 ms long)

For the record I have never seen this on my system using rtl_fm, but I don't
use Pulseaudio. If you only see it when coming out of squelch, what happens
if you disable squelch completely with -l 0?

Perhaps Pulseaudio is sensing the silence samples and pausing playback?

Cheers,
Adam.

[waismocha]

Alexandru,

Thanks for the response.  All of my audio programs play through the pulseaudio server and I know what you are talking about as far as manipulating the streams, I consider this one of the many shining examples of the power of a linux desktop.  It doesn't matter what program I pipe the rtl_fm output to; sox, aplay, mplayer, pacat, etc..  There is some buffering issue, however to the point Adam made below, it's only apparent when using the squelch.

If I tune only one frequency there is no underrun or buffering problems.  So how do you approach that with pulseaudio?  I already tried playing with pacat's latency and latency-msec options with no change, in fact the higher the latency the more problems it seems to have.  I've also tried playing with cache and buffer options in mplayer and sox also to no change.

[waismocha]

Yeah, I noticed that later and also was playing with the -r option.  But anyway it make no difference to my buffer underrun problems.

[Alexandru Csete]

I really don't do anything spectacular in gqrx wrt. to pulseaudio, except set it up for low latency. You can see the whole code is as simple as it can be:
https://github.com/csete/gqrx/blob/master/pulseaudio/pa_sink.cc
It's not even using asynchronous playback.
If it's not the audio system then maybe it's thanks to the gnuradio scheduler which is in charge of executing each DSP block with the properly sized buffers - there really is some magic going on in there that only a few people understand :)

Alex