1
$\begingroup$

I'm trying to get a ham radio listener working with RTLSDR on an old Pentium 4. Unfortunately it is playing for a few seconds, then not playing for a split second, very split up. Is there a way I can adjust this line for better throughput? The odd thing is it wasn't showing all memory used or excessive load (1.37)

rtl_fm -M fm -f 440.72M -l 22 | play -r 24k -t raw -e s -b16 -c 1 -V1 -

Is there a minimum requirement for RTLSDR on XUbuntu or is there a better way I need to tune rtl_fm or play - pipe output?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ When you say the load is 1.37, do you mean the load average? It would be more precise to look at the CPU usage percentage (if it's 100% while running this command then you will certainly get audio buffer underruns). $\endgroup$
    – Kevin Reid AG6YO ♦
    Dec 28, 2019 at 20:41
  • $\begingroup$ There's really too much that could go wrong here; the computational load should be very benign, but the Pentium 4-era USB host controllers were terrible, for example. Also, a Pentium 4 computer uses a lot of power, and thus produces a lot of heat, and thus has a large, potentially loud, fan. Might not be the platform of my choice, to be honest. $\endgroup$
    – Marcus Müller
    Dec 28, 2019 at 22:29

1 Answer 1

Reset to default
2
$\begingroup$

The odd thing is it wasn't showing all memory used or excessive load (1.37)

If I remember correctly, the Pentium IV is a single-core architecture with the option for Hyperthreading, which really is just one core with nearly two pipelines.

Thus, a load > 1 is actually a heavy load.

I would have estimated the load of an RTL-FM reception to be low, but obviously, you're using more than one full core at full speed; that means you're very likely running into dropped samples on the RTL dongle.

Aside from the Pentium IV burning power like a stove, it seems to be too slow for the task at hand. Maybe it's busy with something else? Maybe the inefficient 2000s-era USB host hardware is to blame? Or the inefficient sound card interface? Who knows.

Pentium IV predates a lot of really useful processor instructions for signal processing (it's stuck in the SSE2 era...), so even a NEON-enabled ARM of similar clock speed would often beat it in such loads (e.g. a gen3/gen4 Raspberry Pi executing an ARM64 Debian (not Raspbian, which only uses "old" instructions to stay compatible with the original Raspberry Pi)).

Improve this answer
$\endgroup$
9
  • $\begingroup$ Wouldn't user code running under Raspbian still be able to use newer DSP instructions, even if the kernel itself doesn't? $\endgroup$
    – natevw - AF7TB
    Dec 30, 2019 at 15:43
  • $\begingroup$ good question whether that is technically possible, but I don't think so; it's like if you tried to run a 64 bit application on say a win98SE (which is natively 32 bit): you'd completely have to switch a lot of things in the processor, some of which affect the boundary between OS and userland. $\endgroup$
    – Marcus Müller
    Dec 30, 2019 at 15:56
  • $\begingroup$ My thinking is that memory management and system calls would need to match (although there are 32-bit kernels that support 64-bit apps, xref superuser.com/questions/100780/…). But the OS wouldn't even know what "extra" instructions an app uses so long as they didn't trap. So my guess would be you could manually build software that leveraged DSP opcodes even on Raspbian, but its default package repositories may not have been compiled to take such advantage? $\endgroup$
    – natevw - AF7TB
    Dec 30, 2019 at 16:41
  • $\begingroup$ @natevw-AF7TB it depends very much on architectural details — namely, whether any new registers come into play, and whether the procedure the kernel uses to save/restore state on a context switch accounts for those new registers without any changes being made on the kernel's part. If it all works out wrong, the new SIMD instructions might be effectively impossible to use on a multitasking OS because their dedicated registers could be corrupted at any time. $\endgroup$
    – hobbs - KC2G
    Jan 2, 2020 at 23:04
  • 2
    $\begingroup$ @natevw-AF7TB it seems that for ARM in particular the burden is on the kernel to save/restore VFP/NEON registers as needed, and apps that use them are unusable on kernels without that support: reference stackoverflow.com/questions/31057467/… $\endgroup$
    – hobbs - KC2G
    Jan 2, 2020 at 23:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .