rx_fm using SoapySDR with Airspy mini won't terminate

[Nikotine1]

Hi,

I'm using rx_fm, which uses the SoapySDR, with an Airspy Mini.
The problem is that it won't terminate, the process stays there, using 100% of a processor.
I never get the prompt back, it just sits at Signal caught, exiting.

pi@rpi-rtl-sdr:~ $ /usr/bin/timeout 10 /home/pi/sdr/rx_tools/rx_fm -d driver=airspy -f 137.1M -s 60k -g 30 -p -2 -E deemp -F 9 - | /usr/bin/sox -t raw -e signed-integer -b 16 -r 60k -c 1 - rx_fm.wav rate 11025
Using device Airspy: serial=b5ac67dc2b128913
Found 1 channel(s) :
Channel 0 :
  Found 1 antenna(s): RX
  Found 3 gain(s): LNA MIX VGA
  Found 1 frequencies: RF
  Found 2 sample rates: 6000000 3000000
  Found 0 bandwidths:
[INFO] Using format CS16.
Tuner gain set to 30.00 dB.
Tuner error set to -2 ppm.
Bandwidth set to automatic resulted in 0 Hz.
Tuned to 137580000 Hz.
Oversampling input by: 32x.
Oversampling output by: 1x.
Buffer size: 4.27ms
Sampling at 1920000 S/s.
Output at 60000 Hz.
Signal caught, exiting!

I eventually have to sigkill the process.

I should add that while the above example uses timeout to terminate after 10 seconds, the same happens if I just stop it with ctrl+c.

This doesn't happen with rx_fm (SoapySDR) and an RTL-SDR, and looking at the rx_fm source, it doesn't make a distinction between SDRs, so it must be the SoapySDR Airspy module causing this.

This is on a Raspberry Pi 3B, completely up to date.
Fresh install from source code of SoapySDR, its Airspy module and rx_tools.

[guruofquality]

Its probably stuck in deactivateStream https://github.com/pothosware/SoapyAirspy/blob/master/Streaming.cpp#L205 If I had to guess, but it would be good to start with rx_fm and see which functions get called.

Can you add some strategic prints and see what function its stuck in? Is it a SoapySDR routine, and if so, is it some underlying airspy call like airspy_stop_rx or something like an infinite for loop in SoapyAirspy

[Nikotine1]

While I understand what you mean (add strategic code to write stuff to a log, so you can see where it gets stuck), I must say I'm not a programmer. But it's never to late to learn, so I will try to do a pull request and work with that.

This is the section of code in rx_fm that I believe closes the stream:

        SoapySDRDevice_deactivateStream(dongle.dev, dongle.stream, 0, 0);
	pthread_join(dongle.thread, NULL);
	safe_cond_signal(&demod.ready, &demod.ready_m);
	pthread_join(demod.thread, NULL);
	safe_cond_signal(&output.ready, &output.ready_m);
	pthread_join(output.thread, NULL);
	safe_cond_signal(&controller.hop, &controller.hop_m);
	pthread_join(controller.thread, NULL);

	//dongle_cleanup(&dongle);
	demod_cleanup(&demod);
	output_cleanup(&output);
	controller_cleanup(&controller);

	if (output.file != stdout) {
		fclose(output.file);}

	SoapySDRDevice_closeStream(dongle.dev, dongle.stream);
	SoapySDRDevice_unmake(dongle.dev);
	return EXIT_SUCCESS;

So do you believe I should focus on rx_fm instead?

[guruofquality]

So do you believe I should focus on rx_fm instead?

Thats perfect, its an onion and you have to work your way into the center starting from the outside

Which one of these calls get stuck? That will tell us where to look next.

I dont have an airspy to validate this, but I can do my best to offer suggestions