Fix hackrf receive hangs by checking before each lock wait

Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.


* Sleep for up to 100ms each time waiting for the cond to be kicked;
* Check whether streaming is still enabled each time rather than
  only when the function is entered.

This fixes hangs where consumers like gqrx via gnuradio
will do a stop_rx/start_rx very quickly to change something, and
the buffer receive path is waiting for a buffer.

Signed-off-by: Eric Wild <>
gr3.8 v0.2.3
Adrian Chadd 2 years ago committed by Eric Wild
parent dc82ffd1f8
commit 9b386707d8
  1. 12

@ -30,6 +30,7 @@
#include <stdexcept>
#include <iostream>
#include <chrono>
#include <gnuradio/io_signature.h>
@ -203,8 +204,15 @@ int hackrf_source_c::work( int noutput_items,
std::unique_lock<std::mutex> lock(_buf_mutex);
while (_buf_used < 3 && running) // collect at least 3 buffers
_buf_cond.wait( lock );
while (_buf_used < 3 && running) { // collect at least 3 buffers
_buf_cond.wait_for( lock , std::chrono::milliseconds(100));
// Re-check whether the device has closed or stopped streaming
if ( _dev.get() )
running = (hackrf_is_streaming( _dev.get() ) == HACKRF_TRUE);
running = false;
if ( ! running )