Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.
Now:
* 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.
---
lib/hackrf/hackrf_source_c.cc | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 662d04a..03ea3bd 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -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);
+ else
+ running = false;
+ }
}
if ( ! running )
--
2.28.0
Fix receive path hangs if another thread closes down the hackrf
receive whilst this buffer receive function is waiting to be
woken up.
Now:
* 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.
---
lib/hackrf/hackrf_source_c.cc | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/lib/hackrf/hackrf_source_c.cc b/lib/hackrf/hackrf_source_c.cc
index 662d04a..21656f9 100644
--- a/lib/hackrf/hackrf_source_c.cc
+++ b/lib/hackrf/hackrf_source_c.cc
@@ -30,6 +30,7 @@
#include <stdexcept>
#include <iostream>
+#include <chrono>
#include <gnuradio/io_signature.h>
@@ -203,8 +204,22 @@ 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 );
+ // XXX adrian - tomorrow, turn this loop into a wait_for (1 second)
+ // and re-check dev.get / running !
+ // Otherwise this will hang reasonably reliably if we race where
+ // receive is stopped in one thread, and we've already passed
+ // the hackrf_is_streaming() check; we'll never finish this loop
+ // and consumers (eg gqrx) will fail.
+
+ 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);
+ else
+ running = false;
+ }
}
if ( ! running )
--
2.28.0
There's a current build failure on windows with:
master @ 710d578901a08b091748d4fd4471e3327a4d099e
The issue is in: src/convenience/wavewrite.c, there's an unresolved
external for the gettimeofday function. If you #ifdef the function in (like
done elsewhere), it builds successfully.
Reason i'm building this out right now is that I discovered a weird issue
yesterday, while using rtl_fm + multimon-ng to demod/decode APRS...
Specifically, I noticed that when I did not use the -M fm option, it works,
however when I attempted to explicitly specify -M fm, it did not work. I
was going to debug-in to determine why this would be and found the above
build issue along the way.
If there is a better list to post development issues to, please advise and
i'll join that one instead.
73's
Joseph Armbruster
KJ4JIO
From: Clayton Smith <argilo(a)gmail.com>
This removes gr-iqbal's second-last dependence on Boost. All that
remains is boost::shared_ptr, which will have to stay until GNU Radio
3.9.
---
lib/fix_cc.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/fix_cc.cc b/lib/fix_cc.cc
index af79d7db26..628421db3e 100644
--- a/lib/fix_cc.cc
+++ b/lib/fix_cc.cc
@@ -43,7 +43,7 @@ iqbalance::fix_cc::fix_cc(float mag, float phase)
{
message_port_register_in(pmt::mp("iqbal_corr"));
set_msg_handler(pmt::mp("iqbal_corr"),
- boost::bind(&iqbalance::fix_cc::apply_new_corrections, this, boost::placeholders::_1));
+ std::bind(&iqbalance::fix_cc::apply_new_corrections, this, std::placeholders::_1));
}
--
2.25.1
Dear Maintainers,
The attached patch adds XTRX SDR support to Gr-Osmosdr. It mostly contains the out-of tree patches added in the libxtrx branch here: https://github.com/xtrx-sdr/gr-osmosdr , also the patches upstreamed to be compatible with Gnu-Radio 3.8 and the latest master branch of gr-osmosdr.
It compiles and works fine with Gnu-Radio 3.8 and Gr-Osmosdr master (tested on Ubuntu 20.04.01 LTS 64bit).
Hopefully I will have time to test it against other Osmocom projects in the near future.
Please let me know if the patch needs any modifications or further work.
Regards,
Csaba
Dear fellow Osmocom developers,
as you all know, we've sadly had to postpone OsmoDevCon 2020 back in
April this year. At the time, we discussed to re-visit the situation
in October 2020.
While legally it is no problem at all to host an event with ~ 20
participants in Berlin/Germany (specific regulations really only start
from 50+ participants) - I'm not entirely convinced it would be the
smartest move.
Legality and public health regulations are only one part of the equation
- common sense and profound care for the key members of our community
for sure are more relevant considerations to me.
I'm not 100% in favour and not 100% against. Hence, I would like to get
your input. Should we
a) try to get an event organized on-site in Berlin? We'd have to move
to a larger venue than IN-Berlin with proper ventilation and sufficient
space so we can keep physical distance, but I think that's
manageable for sysmocom as organizer.
b) simply postpone to 2021? I'm convinced the situation will not change
significantly (in a positive way) until late April 2021, so it's not
really a "solution" as it will likely mean we have to think of late
2021 or 2022.
c) plan some kind of online conference? To be honest, I think this
model works fine for events where a single speaker wants to give
lectures to hundreds or thousands of participants. But OsmoDevCon
is much more interactive. We could record or live-stream some talks
or screencasts from home, sure. But that only captures one part of
the event. We could also try to set a date for a collaborative
mumble, or the like - for the "hallway track".
What are your thoughts? Let's avoid cross-posting the discussion to all
of the mailing lists and simply have it on openbsc(a)lists.osmocom.org.
Regards,
Harald
--
- Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
