search

f4exb / sdrangel

SDR Rx/Tx software for Airspy, Airspy HF+, BladeRF, HackRF, LimeSDR, PlutoSDR, RTL-SDR, SDRplay and FunCube
GNU General Public License v3.0
2.87k stars 435 forks source link

Program freezes when modulator added or device sink stopped #210

Closed jigpu closed 6 years ago

jigpu commented 6 years ago

I often run into issues with the program freezing when trying to use the NFM modulator with my LimeSDR-mini. Unless I'm very careful about the sequence in which I configure the sink and modulator, the program freezes. While trying to isolate the cause, I've found that the program can be made to freeze even without any hardware attached by using the FileSink.

Running sdrangel under gdb and grabbing backtraces of all threads shows that only two threads aren't idling in poll(): the main sdrangel thread (trying to write to an audio fifo) and a second thread thread under the control of PulseAudio.

The program seems to freeze any time a modulator is available while the sink is stopped. This can be either because you added a modulator before starting the sink (first variant), or because you stopped a sink prior to removing the modulator (second variant).

Steps to reproduce:

Configuration:

GDB Log:

KC7NOA commented 6 years ago

USB2.0 OR USB3.0?

I have a similar issue when changing antenna settings ... i have a thread here about it ....

For me ... getting a PCIe-2.0 to USB3.0 card cleard up almost all issues i had ...

jigpu commented 6 years ago

I do also run into issues changing transmit settings on my LimeSDR-mini (antenna, frequency, transmit power, etc.). I assume its related to this issue but don't have any hard proof*. The stick is plugged into a port on the motherboard marked USB 3.0, although something odd is going on with it since the system indicates the device is behind one of the USB 2.0 root hubs :confused:. I'll have to investigate that further and hope that 3.0 improves those issues. Regardless, this particular issue isn't device or USB speed dependent :smile:

*My guess at the probable mechanism would be a temporary stall when reconfiguring the device which behaves similar to the sink being stopped. Not sure how to explain USB 3.0 fixing the issue though unless the card doesn't respond as fast on 2.0 (e.g. because of bandwidth issues -- which wouldn't be too surprising for the Lime).

crashdump commented 6 years ago

I've encountered the same issue (LimeSDR). It seems some USB 3 ports are more prone to have the issue than other and since I have plugged the device directly to the motherboard I don't see it as frequently.

f4exb commented 6 years ago

The issue has nothing to do with USB or the Lime or... so let's focus on the original issue. I have encountered the same thing but only on a Virtualbox VM running on a Win10 host. By aborting the program with a core dump (Ctl-]) I see the program hanging at the very same place:

#0  0x00007ffff5b54ef6 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0
#1  0x00007ffff6ca869d in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5
#2  0x00007ffff7d38a7d in AudioFifo::write(unsigned char const*, unsigned int, int) (this=0x555555f00318, data=data@entry=0x555556b04528 "\240", numSamples=numSamples@entry=480, timeout_ms=timeout_ms@entry=10)
    at /usr/src/debug/sdrangel/sdrbase/audio/audiofifo.cpp:109
#3  0x00007ffff7d39b14 in AudioInput::writeData(char const*, long long) (this=0x555556fadbf0, data=0x555556b04528 "\240", len=1920) at /usr/src/debug/sdrangel/sdrbase/audio/audioinput.cpp:184
...

So the issue is somewhere there possibly with a mutex mishmash. By commenting the write in AudioInput the program runs normally (but wouldn't be able to use the audio input) which tends to confirm that the problem is there.

Funny enough this does not seem to occur with all audio devices.

f4exb commented 6 years ago

It seems that the way the AudioFifo is written makes it lock when samples are not read fast enough. As soon as it enters the "full" state it gets locked at the QWaitCondition::wait. I think this bit of code could be skipped entirely as when it's full, it's full... Similarly on the read side, when it's empty, it's empty... This would avoid entering into dead loops with mutexes for no good reason at all. Mutexes are dangerous beasts that should be used only if absolutely necessary.

It may happen possibly because the modulator does not pull the audio samples fast enough which could be a different issue.

f4exb commented 6 years ago

Fix delivered in v4.1.0